Valery Smyslov writes:
> SKEYSEED = prf(Ni | Nr, g^ir)
> {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+
> (SKEYSEED, Ni | Nr | SPIi | SPIr)
>
> This change was intentional, it was made by Hugo Krawczyk during
> work on IKEv2 due to complaints from the community that if IKEv1 PSK
> auth mode was used in IKEv2 then it would be impossible for
> responder to select proper preshared secret based on initiator's
> identity (like in IKEv1 Main Mode). As far as I remember, when
> making this change Hugo mentioned, that it would weaken security of
> the protocol.Yes, the problem was that PSK was needed to decrypt the IKE packet to be able to see the ID, so ID was useless for selecting PSK. Because of this people used aggressive mode in IKEv1, so PSK could be selected based on the ID. Also if the PSK was wrong then the decryption simply failed and that made it hard to know what went wrong. For the responder he just needed to know which PSK to use based on the source IP address, and that worked fine with fixed vpn links, but not with mobile users. In IKEv2 we decided to use the PSK only for the authentication, and not tie it up to the key generation. Most of the PSKs used in real world are not cryptografilly strong enough to provide that much more security for the SKEYSEED calculation. When we were talking about the draft-nagayama-ipsecme-ipsec-with-qkd draft (now expired) we discussed that we should just add the QKDdata SKEYSEED calculation. (Hmm... it seems that my comments (attached) about the draft-nagayama-ipsecme-ipsec-with-qkd draft never made to the list). In that email I proposed changing the SKEYSEED calculation so ti would include QKDdata: SKEYSEED = prf(Ni | Nr, g^ir | QKDdata) On the other hand this would still bring exactly same problems we had with IKEv1 related to what happens if QKDdata do not match. We would not have the ID issue, as the QKDdata is selected based on the different payload, i.e. QKD KeyID would select what QKDdata is used, and that is sent in the IKE_SA_INIT which is not encrypted. I also proposed to change the QKD draft to be more generic, i.e. generic out of band one time shared key usage protocol, i.e. not specifically tied to the QKD. I.e. we discussed about distributing strong shared data using DVDs or similars, and just sending offsets for the shared data to be used. Other option is to only augment the KEYMAT, i.e. the actual IPsec traffic key materials used. I.e. change KEYMAT = prf+(SK_d, Ni | Nr) to KEYMAT = prf+(SK_d, Ni | Nr | QKDdata) I.e in that case attacker who can break DH would be able to see the IKEv2 SA traffic, i.e. the IDs, key exchanges etc, but still would not be able to decrypt the actual ESP traffic without getting the QKDdata too. The only secret thing in the IKE SA traffic is the IDs, but if we use the QKDdata to generate encryption keys, then that QKD KeyID is a form of ID, that most likely can already be used to derive the actual user id (depends how that QKD KeyID is generated). The IKE SA traffic needs to be protected for real time changes, but there is not that big value for protecting them for long term decryption. On the other hand ESP traffic is the one that really benefits from long term decryption protection. > Does NSA mean this difference when claiming that IKEv1 PSK mode is the only > QC-safe protocol? Should we add similar mode to IKEv2? I think we should continue pushing the draft-nagayama-ipsecme-ipsec-with-qkd forward, and specify it as generic method where out of band shared keys can be brought in to the SKEYSEED or KEYMAT. -- [email protected]
ipsec-ietf-org-kivinen-21624.29487.515060.335151@fireball.kivinen.iki.fi
Description: Binary data
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
