Hi Valery, Thanks so much for the quick turnaround! The draft is nicely written, and I'm happy that it addresses the broader problem.
I just have two questions on the draft. First, I understand the intent of the extension to be to have each party sign the entire transcript of the IKE_SA_INIT exchange. Is that what's happening here? I ask because I'm not precisely sure what parts of the transcript are specified here: https://www.ietf.org/archive/id/draft-smyslov-ipsecme-ikev2-downgrade-prevention-00.html#section-6-5 Second, if I understand correctly, the extension itself may be subject to downgrade attack. A responder might support the extension in one of two modes (likewise for the initiator): 1. Optional: if the initiator offers the extension, then the responder will always select it 2. Mandatory: if the client doesn't offer the extension, then the responder aborts If support is optional, then the attacker could remove support for the strong key exchange algorithm *AND* remove support for the extension in the initiator's IKE_SA_INIT message. On the other hand, if support is mandatory, then this rewrite would always be detected by the initiator. Do you agree? I called this the "bootstrap" problem upthread: the downgrade threat exists as long as the downgrade protection mechanism itself isn't mandatory. I don't think there's away to solve this problem, other than to gradually transition to mandatory downgrade protection. Though I feel optimistic that this transition can get done by Q-day. Finally, a typo: "usese" => "uses" Best, Chris P. On Thu, Jun 26, 2025 at 3:34 AM Valery Smyslov <[email protected]> wrote: > Hi Chris, all, > > > > I published a draft [1] that defines an IKEv2 extension aimed to address > the problem. > > > > Regards, > > Valery. > > > > [1] > https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-downgrade-prevention/ > > > > > > *From:* Christopher Patton <[email protected]> > *Sent:* Wednesday, May 28, 2025 11:47 PM > *To:* [email protected] > *Subject:* [IPsec] Re: Binding properties of > draft-ietf-ipsecme-ikev2-mlkem-00 > > > > 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]
