From: Valery Smyslov <[email protected]> Sent: Wednesday, July 04, 2018 4:59 AM To: 'Daniel Van Geest' <[email protected]>; [email protected] Cc: Scott Fluhrer (sfluhrer) <[email protected]> Subject: RE: IKE_AUX comments
Hi Daniel, thank you for your comments. See responses inline. Additionally, Scott pointed out to me that Integrity Check Values aren’t designed to be secure against someone who knows the key (which would be the case for a Quantum-enabled attacker) and that for algorithms like GMAC the attacker would be able to find a collision. So then your statement later: THe forgery would become evident in the IKE_AUTH exchange (provided the attacker caanot break employed authentication mechanism) wouldn’t hold; an attacker could find a forgery with the same ICV and IKE_AUTH exchange would succeed. OK I agree that for the current definition of how IKE_AUX is authenticated this statement is not accurate. But regardless of that, AEAD is a good enough reason why ICVs shouldn’t be used here. Presumably you don’t want to include the whole data for the entire set of IKE_AUX exchanges in the signed octets because that would mean persisting the data for all IKE_AUX exchanges until IKE_AUTH is processed, requiring a lot of extra buffer state and increasing the attack surface for buffer exhausting? Exactly. A second-preimage-resistant hash function is needed to use a digest of the IKE_AUX messages in the signed octets. This algorithm could possibly be negotiated in the AUX_EXCHANGE_SUPPORTED notification data. I’d rather to avoid using an additional algorithm. I think the negotiated PRF can be used for this purpose, can’t it? InitiatorSignedOctets = RealMessage1 | AUX_I | NonceRData | MACedIDForI AUX_I = PRF(SK_pi, AUX_INIT_MSG_1) | PRF(SK_pi, AUX_INIT_MSG_2)| PRF(SK_pi, AUX_INIT_MSG_3) ... ResponderSignedOctets = RealMessage2 | AUX_R | NonceIData | MACedIDForR AUX_R = PRF(SK_pr, AUX_RESP_MSG_1) | PRF(SK_pr, AUX_RESP_MSG_2)| PRF(SK_pr, AUX_RESP_MSG_3) ... I used SK_pi/r instead of SK_ai/r here because their size fits the preferred key length for PRF (that is not generally the case for SK_ai/r). So, what do you think? Is this construction secure? My comment assumed that we were using IKE_AUX this way; we perform an initial key exchange during the IKE_INIT; this will generate keying material which we will use to protect the initial IKE_AUX message; then, we will perform a second key exchange during the IKE_AUX, which would be used to generate a second set of keying material; this will be used to protect the next IKE messages (which might be another IKE_AUX, or it might be the IKE_AUTH).. If we assume an adversary that can break the initial key exchange while the protocol is running (e.g. it’s an (EC)DH exchange, and he has a fairly advanced quantum computer), then he can learn the SK_pi, SK_pr values. The problem is that, with some PRF’s, if you know the key, you can find a second message with the same PRF value as a given message; hence our MITM would be able to introduce his own key shares, and leave the PRF value unmodified. From the IANA PRF registry, all the HMAC-based PRFs would be safe (that is, make this attack infeasible, at least in real time), while PRF_AES128_XCBC and PRF_AES128_CMAC are not; given a 128 bit block within the message that the attacker can set arbitrarily, it is easy to find the setting to make the PRF value be whatever the attacker chooses (including the PRF of another message). And, yes, this is a situation where MD5 is actually stronger than AES… What could an attacker do with this capability? Well, depending on the later key exchange, an attacker may be able to insert his own key shares in such a way that both sides obtain the same shared secret (that the attacker would know); this means that the attacker would have succeeded in listening in (as everything used to compute InitiatorSignedOctets and ResponderSignedOctets are exactly the same as in the non-MITM case) There are some details that I’m omitting that may make this attack more difficult than I outlined; however I don’t believe we should depend on those details. One thing we might consider to address this is limiting the PRF’s to those which disallow preimage attacks (even if the attacker knows the key); those would be HMAC-based (and KMAC-based if the WG actually defines such a PRF). Regards, Valery. Thanks, Daniel
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
