Last year, NSA made an announcement about how to deal with the potentiality of someone developing a Quantum Computer; (https://www.nsa.gov/ia/programs/suiteb_cryptography/). Among their recommendations was the advice that:
"CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys and the AES-256 encryption algorithm. RFC 2409 is the only version of the IKE standard that leverages symmetric pre-shared keys in a manner that may achieve quantum resistant confidentiality. The reason they gave this advise was the IKEv1, unlike IKEv2, stirred in the preshared key into the KDF function (along with the (EC)DH shared secret); hence if the preshared key was strong, then Shor's algorithm (which can recover the (EC)DH shared secret) is not enough to recover the negotiated keys. Now, we don't want people to migrate back to an obsolete version of the protocol; hence we've devised a way to strengthen IKEv2 the same way. It was considered important to minimize the changes made to IKEv2. From a cryptographical prespective, the only change we make is that we modify the nonces that we present to the KDF. By keeping the cryptographical changes minimal, we reduce the risk of accidentally introducing a weakness. Like IKEv1, this solution assumes that the initiator and the responder share a secret string (called a PPK in the draft). However, unlike IKEv1, that is not the only authentication that's in the system. We leave the existing authentication methods in place, and add this in addition. One thing that was a source of complexity was that we did not want to assume that every system had the same PPK; that instead that systems would want a pairwise PPK. However, if a responder configured its PPK on a per-peer basis, and didn't learn the peer until after an IKEv2 tunnel has been established, that would mean that the responder would need to know the PPK before it officially learned the peer. To solve this, we added the PPK_REQUEST/PPK_ENCODE notifications to give the responder a hint about which PPK to use (without leaking the identity to third parties). Would anyone be willing to review this draft? I believe that we have a need for such a solution.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
