Hi Chris,
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.)
I assume that SK_I and SK_E are long-term shared secrets used for
authentication?
Just to clarify, because in RFC 7296 those secrets are called PSKs,
while SK_* are session keys.
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.
I fail to understand how the latter could help. The attacker modifies
initiator’s IKE_SA_INIT message anyway and thus can
replace initiator’s identity with ID_E, if it were there. Including both
IKE_SA_INIT messages into the authentication
blob could have helped.
Do folks believe this attack? Am I missing a detail of the protocol that
mitigates it?
This looks like combination of downgrade and UKS (unknown key share) attacks.
I believe it is feasible. However, there are some additional prerequisites for
it to happen:
1. Both initiator and responder are configured to allow ECDH-only key
exchange (using ML-KEM is optional for both).
In other words, they _both_ don’t care whether ML-KEM is used or not. In case
of initiator
this is explicitly indicated in the IKE_SA_INIT message (an AKE* transform in
SA payload includes NONE as a valid choice).
Thus, they intentionally allows to put themselves under attack if ECDH is
breakable.
2. The responder accepts initiator’s identity ID_E and does have an
associated key SK_E to verify it.
In other words, E is a legitimate user whose long-term key is compromised.
Note, that in this case the attacker can just impersonate it, even if ECDH is
not breakable and/or ML-KEM is used.
The possible mitigation is to use less restrictive policy for either
initiator or responder or both.
Since the victim of this attack is initiator, it is reasonable for
she/he to require use ML-KEM in this case.
Regards,
Valery.
[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]
