From: Valery Smyslov [mailto:[email protected]] Sent: Tuesday, January 12, 2016 3:09 AM To: Panos Kampanakis (pkampana); Perlner, Ray; [email protected] Cc: Liu, Yi-Kai; David McGrew (mcgrew); Waltermire, David A.; Frankel, Sheila E.; Scott Fluhrer (sfluhrer); Moody, Dustin Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
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. That is certainly a reasonable suggestion. 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. There are two uses of crypto within the protocol: - It defines the transform of the nonce from the on-the-wire version into the one presented to the IKEv2 KDF (mixing in the PPK). - The initiator gives an indication of which PPK to use (without leaking any information about it to someone two doesn't know the value). For the first use, it would be reasonable to have the initiator define a bitmask of the algorithms it supports, and the responder to select one This second use is rather trickier to have agility; it is sent before the initiator has any contact to the responder. I don't see how the responder can indicate which algorithms it supports (without adding a round trip to the protocol). I don't see any really good alternatives: - The initiator could send an indication about which algorithm it is used to encode the ppk (and the responder either understands it or rejects it). I don't see how that is much of an improvement. - The initiator could send the indication with multiple algorithms (and the responder selects which one it supports); however that strikes me as secure as the weakest of the supported algorithms (because if one of them leaks any information, the attacker learns that leakage). We can update the draft to use a status notification, and to have a negotiated nonce transform; I think we'll leave the indication algorithm fixed (as I don't see a good alternative). Regards, Valery Smyslov. ----- Original Message ----- From: Panos Kampanakis (pkampana)<mailto:[email protected]> To: Perlner, Ray<mailto:[email protected]> ; [email protected]<mailto:[email protected]> Cc: Liu, Yi-Kai<mailto:[email protected]> ; David McGrew (mcgrew)<mailto:[email protected]> ; Waltermire, David A.<mailto:[email protected]> ; Frankel, Sheila E.<mailto:[email protected]> ; Scott Fluhrer (sfluhrer)<mailto:[email protected]> ; Moody, Dustin<mailto:[email protected]> 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]<mailto:[email protected]> Cc: Liu, Yi-Kai <[email protected]<mailto:[email protected]>>; Moody, Dustin <[email protected]<mailto:[email protected]>>; Frankel, Sheila E. <[email protected]<mailto:[email protected]>>; Waltermire, David A. <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
