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]
