Hi Panos, thank you for sharing this draft. A couple of quick comments.
First, I think that it is better to use a new status Notification to negotiate this feature rather than a Vendor ID payload. It is more in line with the way other IKEv2 extensions are negotiated and it would allow not to waste 16 bytes in the IKE_SA_INIT messages. And second, I'm not comfortable with using fixed algorithms (AES, HMAC_SHA2) and not addressing algorithm agility. Fortunately, your draft says that this might change in future versions. I think it is an important feature ant I hope it'll be addressed. Regards, Valery Smyslov. ----- Original Message ----- From: Panos Kampanakis (pkampana) To: Perlner, Ray ; [email protected] Cc: Liu, Yi-Kai ; David McGrew (mcgrew) ; Waltermire, David A. ; Frankel, Sheila E. ; Scott Fluhrer (sfluhrer) ; Moody, Dustin Sent: Tuesday, January 12, 2016 8:44 AM Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi Ray, Scott's https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the first take of QC resistant IKEv2. It is still in its early stages and has not been adopted as any WG's item yet. Feedback is welcome. Rgs, Panos From: IPsec [mailto:[email protected]] On Behalf Of Perlner, Ray Sent: Wednesday, January 06, 2016 3:33 PM To: [email protected] Cc: Liu, Yi-Kai <[email protected]>; Moody, Dustin <[email protected]>; Frankel, Sheila E. <[email protected]>; Waltermire, David A. <[email protected]> Subject: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi all. NIST is investigating quantum-resistant alternatives to presently standardized public-key algorithms. We are reaching out to the IPSec working group to determine if there are any unique needs associated with trying to add quantum-resistance to IKEv2, which currently only uses variants of the Diffie-Hellman key exchange. We believe a number of the properties of the Diffie-Hellman construction (such as perfect forward secrecy) can be met using generic constructions based on standard cryptographic primitives and security models (such as IND-CCA2 encryption and EUF-CMA signature) as long as key generation times are fast. If IKEv2 can accommodate such generic constructions, there are likely to be many proposals to choose from. However, there are some additional properties of the Diffie-Hellman exchange which may be difficult to duplicate (such as the property that the responder can compute his key exchange message without seeing the initiator's key-exchange message) and it's not as clear to us what the security model for a key exchange replacing DH should be. So in summary, we would like to answers to the following questions: 1) Can IKEv2 can be modified to replace the Diffie-Hellman exchange with a generic construction based on standard encryption, signature, and PRF primitives? 2) If not, what specific security and correctness requirements should we target to meet the need? Thanks, Ray ------------------------------------------------------------------------------ _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
