Hi Scott,
thank you for clarification. Please, see 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).. Yes, that’s how I think it should work. 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… OK, I see the problem. My (false) premise was that PRF in general has stronger cryptographic properties than MAC, but now I see that in situation when attacker knows key some PRFs behave badly regarding second-preimage resistance. So, using PRF won’t really help here (if we’re talking about arbitrary PRF). 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). So, our options are: 1. Using IKE_AUX messages themselves: InitiatorSignedOctets = RealMessage1 | AUX_INIT_MSG_1 | AUX_INIT_MSG_2 | AUX_INIT_MSG_3 ... | NonceRData | MACedIDForI ResponderSignedOctets = RealMessage2 | AUX_RESP_MSG_1 | AUX_RESP_MSG_2 | AUX_RESP_MSG_3 ... | NonceIData | MACedIDForR This approach has a disadvantage that implementation needs to keep all IKE_AUX messages (which might be quite large) until it receives IKE_AUTH, that increases vulnerability to DoS attack. 2. Using hashes of IKE_AUX messages (as Daniel proposed): InitiatorSignedOctets = RealMessage1 | H(AUX_INIT_MSG_1) | H(AUX_INIT_MSG_2) | H(AUX_INIT_MSG_3) ... | NonceRData | MACedIDForI ResponderSignedOctets = RealMessage2 | H(AUX_RESP_MSG_1) | H(AUX_RESP_MSG_2) | H(AUX_RESP_MSG_3) ... | NonceIData | MACedIDForR where H is a collision-resistant hash function. The problem with this approach is that it would require to add a new crypto primitive (hash), that is not currently present in a set of negotiated parameters. So a new negotiation mechanism would be needed (or a new Transform Type) and a new IANA registry. And all this would increase the IKE_SA_INIT messages size. 3. Using the PRFs as outlined above, but limiting PRFs to only those, which are preimage resistant even if key is known (as you proposed). From the current set of PRFs registered for IKEv2 in IANA this would leave out PRF_AES128_XCBC and PRF_AES128_CMAC, that don’t provide enough security in post-quantum world anyway (due to their 128 bit internal key). Any other options? Any thoughts? Regards, Valery. Thanks, Daniel
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
