HI Valery, We thought about this mode, but decided it didn't make sense. It would seem to allow the malicious initiator E to impersonate responder R to initiator I. No quantum computer needed! Do you think there's any chance that deployments do this in practice?
Chris P. On Fri, May 23, 2025 at 6:19 AM Valery Smyslov <smyslov.i...@gmail.com> wrote: > Hi Chris, > > > > IKEv2 allows peers to use different PSKs for authentication initiator and > responder (but both peers must have both these PSKs). > > So, _*theoretically*_ it is not unrealistic that each peer uses a > separate PSK to authenticate itself, > > and one of these PSKs is compromised, while the other is not (no matter > how this can happen). > > Weird, but possible. But I agree that in practice one PSK is used to > authenticate in both directions. > > > > The attack is also possible with signature authentication mode when > initiator’s private key is compromised. > > > > Regards, > > Valery. > > > > > > Hi all, > > > > A quick follow-up here: This attack doesn't seem to work for the > authentication mode in which the initiator and responder MAC their outbound > messages with a PSK. The responder IKE_AUTH message would be MAC'ed by the > PSK shared with initiator E, not initiator I. Thus initiator I would abort > the protocol in Step (10). (Credit to Bas Westerbaan for pointing this out.) > > > > This specific attack seems to require the responder to sign its IKE_AUTH > with a digital signature. However the lack of downgrade resilience makes me > worry there might be variants for other authentication modes, including > MAC. I'm curious how much flexibility there is in IKEv2 for supporting > different modes of authentication. > > > > Chris P. > > > > > > > > On Mon, May 19, 2025 at 2:39 PM Christopher Patton <cpat...@cloudflare.com> > 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 <smyslov.i...@gmail.com> > 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 -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
