Impersonation is not interesting here. The goal of attacker is to downgrade secure connection between peers so that it can break ECDH and read their communication. So, this is an active attack, but the goal is eavesdropping. Consider initiator I has some sensitive information to send to responder R and attacker E has the long-term I’s key and also has a CRQC. Impersonation doesn’t help E to know this information, downgrade attack and eavesdropping does. The question remains whether initiator I will send sensitive information over the downgraded channel being aware of quantum threat. This is a matter of policy J 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 <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[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] <mailto:[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> 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]
