Hi all, I appreciate the productive discussion here! I've asked the chairs for time at IETF 123 to discuss if/how to address this problem.
Chris P. On Mon, May 19, 2025 at 2:39 PM Christopher Patton <[email protected]> wrote: > Digging into this a little deeper, I believe the downgrade attack > described in Section 5.2.1 of [1] is relevant here. > > Suppose I have broken ECDH and want to impersonate some responder R to > some initiator I. I don't have access to I's MAC key SK_I, but I do have > access to another initiator E's MAC key SK_E. (In fact, I might actually be > E.) The attack starts like this (cf. Figure 7 of [1]): > > (1) Intercept the IKE_SA_INIT from initiator I > (2) Modify the intercepted IKE_SA_INIT by dropping support for ML-KEM > (3) Forward the modified IKE_SA_INIT to responder R > (4) Forward the IKE_SA_INIT from responder R to initiator I > > At this point, responder R has chosen ECDH only, which means the initiator > I has completed an ECDH key exchange and is ready to produce its AUTH > message. (No intermediate ML-KEM exchange is done because R believes the > initiator didn't offer it.) The attack proceeds as follows: > > (5) Intercept the AUTH from I > (6) Decrypt the payload (requires solving a discrete logarithm in the ECDH > group) > (7) Replace the MAC of the real IKE_SA_INIT message from step (1) under > SK_I with the MAC of the modified IKE_SA_INIT from step (2) message under > SK_E > (8) Encrypt the modified payload > (9) Forward the modified AUTH to responder R > (10) Forward the AUTH from R to I > > Step (9) succeeds because the responder believes it has been talking to > initiator E rather than initiator I.At this point, initiator I and R have > exchanged a session key that the attacker has access to. > > This attack exploits the fact that each MAC only covers the messages sent, > not the messages received. In particular, if R also MACed the initiator's > IKE_SA_INIT message, then I would not accept its AUTH message. It may also > have helped if the initiator's IKE_SA_INIT contained its identity; this way > the responder would not have accepted an AUTH message from E. > > Do folks believe this attack? Am I missing a detail of the protocol that > mitigates it? > > [1] https://eprint.iacr.org/2016/072 > > > On Sun, May 18, 2025 at 11:40 PM Valery Smyslov <[email protected]> > wrote: > >> Hi Chris, >> >> >> >> Hi all, >> >> >> >> I'm reviewing draft-ietf-ipsecme-ikev2-mlkem-00 [1] and had a few >> questions about its hybrid security. Forgive me if this concern has already >> been raised and addressed, as I'm new to this mailing list. I briefly >> searched the archive and didn't find a related thread. >> >> >> >> Suppose we do ECDH for the initial key exchange and ML-KEM for the first >> intermediate key exchange. I understand the key exchange to work roughly as >> follows. >> >> >> >> The key exchange involves the following values: >> >> - Ni // Initiator's nonce >> >> - Nr // Responder's nonce >> >> - SPIi // Initiator's SPI >> >> - SPIr // Responder's SPI >> >> - KEi(0) // Initiator's ECDH key share >> >> - KEr(0) // Responder's ECH key share >> >> - KEi(1) // ML-KEM public key >> >> - KEr(1) // ML-KEM ciphertext >> >> >> >> The key schedule is as follows: >> >> 1. KEi(0) and KEr(0) are combined to form shared secret SK(0) >> >> 2. SKEYSEED(0) is derived from prf(Ni | Nr, SK(0)) >> >> 3. SK_d(0) is derived from prf+ (SKEYSEED(0), Ni | Nr | SPIi | SPIr ) >> >> 4. KEi(1) and KEr(1) are combined to form shared secret SK(1) >> >> 5. SKEYSEED(1) is derived from prf(SK_d(0), SK(1) | Ni | Nr) >> >> >> >> Finally, SKEYSEED(1) is used to derive session keys or to carry out >> another intermediate key exchange. Do I understand this right? >> >> >> >> Yes. >> >> >> >> This is similar to what TLS 1.3 does [2]: session keys are derived by >> mixing the shared secrets SK(0), SK(1) and binding them to some protocol >> context Ni, Nr, SPIi, SPIr. However, there is an important difference: in >> TLS 1.3, the protocol context includes the ECDH key shares and the ML-KEM >> public key and ciphertext; in IKEv2, the protocol context does not include >> these values. >> >> >> >> This difference is interesting when we think of the key schedule as a >> "KEM combiner" [3]. In TLS 1.3, the combiner binds the key to the ECDH >> key shares and ML-KEM public key and ciphertext; in IKEv2, the combiner >> does not. This means the combiner is not robust [4], meaning a weakness in >> ECDH or ML-KEM could imply a weakness in the hybrid KEM. >> >> >> >> Of course, whether this is a problem for IKEv2 depends on what properties >> of the combiner are needed for the security of the protocol. The draft >> cites a proof of IND-CPA security for the combiner, thus we'd need to be >> able to prove IKEv2 secure based on the assumption that one of ECDH or >> ML-KEM is IND-CPA. Do I understand that right? >> >> >> >> Assuming I've got this all correct, I'd be curious to know if this >> working group considered whether or not to bind the key to the key exchange >> messages. On the one hand, it seems like doing so would require changing >> the IKEv2 key schedule, which is probably undesirable. On the other hand, >> it might be useful for proving stronger-than-usual security properties of >> IKEv2, even if it's not strictly necessary for authenticated key exchange. >> >> >> >> Unless I’m missing your point, I believe that the binding of >> shared secrets to the protocol context >> >> in IKEv2 is done via the way the content of the AUTH payload is >> calculated. >> >> >> >> For pure IKEv2 (RFC 7296 Section 2.15) for initiator: >> >> >> >> BLOBi = MSGi | Nr | prf(SKpi, IDi) >> >> >> >> where MSGi – initiator’s IKE_SA_INIT message (includes >> initiator’s ECDH key share) >> >> SKpi is derived from SKEYSEED >> >> >> >> >> >> In the case of hybrid key exchange ECDN+ML-KEM (RFC 9242, >> Section 3.3.2) for initiator: >> >> >> >> BLOBi = MSGi | Nr | prf(SKpi(1), IDi) | prf(SKpi(0), INTi) | prf >> (SKpr(0), INTr) | 2 >> >> >> >> where MSGi - initiator’s IKE_SA_INIT message (includes >> initiator’s ECDH key share) >> >> SKpi(1) – derived from SKEYSEED(1) >> >> INTi – initiator’s IKE_INTERMEDIATE message before its >> encryption (includes initiator’s ML-KEM public key), >> >> INTr – responder’s IKE_INTERMEDIATE message before its >> encryption (includes ML-KEM ciphertext), >> >> SKpi(0), SKpr(0) – derived from SKEYSEED(0) >> >> >> >> >> >> BLOBi is then signed or MACed, which in my understanding >> provides the necessary binding of the keys to the IKEv2 context. >> >> >> >> Regards, >> >> Valery. >> >> >> >> On an unrelated note, I'm curious about the language around input >> validation in >> https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-mlkem-00.html#section-2.3. >> Namely, why use SHOULD instead of MUST for validating inputs? >> >> >> >> Thanks, >> >> Chris P. >> >> >> >> >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ >> >> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ >> >> [3] https://datatracker.ietf.org/doc/draft-irtf-cfrg-hybrid-kems/ >> >> [4] https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design/ >> >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
