On 2025-07-21 10:12 a.m., Jun Hu (Nokia) wrote:
just got time to read through this thread, this downgrade attack requires both
peers to allow IKEv2 with only weak DH, it won’t work if either peer only
allows strong DH or a hybrid DH include strong DH.
Such attack is valid on theory, but I wonder how likely a real deployment is
vulnerable?
In a quantum attack scenario, there is no such thing as a strong DH. However,
a DH is necessary to bootstrap to RFC 9370 hybrid.
All IPsec deployments I have seen have all IPsec peers either belongs to by
same organization, or have some control (e.g.require certain version of 3rd
party client) by the same organization, typically there are two types of
deployements:
1. Hub-and-spoke, with clients and a gateway like road-warrior VPN
* Gateway policy configuration: typically there is no per client
configuration, a single gateway config is likely to allow both strong and weak
DH so that it covers clients with different capabilities.
This draft protects exactly this scenario. Since the server supports clients
with different capabilities, this draft will protect those clients which
implement it against downgrade attack. Once the gateway can be sure that all
clients support RFC 9370 with the desired algorithms it can raise the bar on
its policy enforcement and this draft wouldn't be necessary. But as long as it
supports weaker clients, the stronger clients would be vulnerable to downgrade
attack without additional mitigation.
* Client policy configuration: typically there is per gateway
configuration, so if the clients supports strong DH and know that a specific
gateway also support strong DH, it could have configuration that disallow using
only weak DH for the gateway; in other words, the downgrade attack won’t work
1. Mesh, like router-to-router: typically there is per-peer configuration,
so if a given Ipsec system support strong DH and know for a specific peer also
supports strong DH, then same as 1b, it could have configuration disallow using
only weak DH for the peer.
so I think this attack could be prevent by using strict policy configuration on
at least one peer, with assumption that at least one side knows the capability
of both peers
Maybe this is the crux of the scenario I responded to above. In the road
warrior scenario with clients with different capabilities, are you expecting
that the gateway knows the capabilities of all the clients who could possibly
connect to it?
Regards,
Daniel
From: Valery Smyslov <[email protected]><mailto:[email protected]>
Sent: Thursday, July 10, 2025 8:20 PM
To: 'Christopher Patton' <[email protected]><mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
HI Chris,
thank you for your review. Please, see inline.
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
RealMessage1 is the IKE_SA_INIT request and RealMessage2 is the
IKE_SA_INIT response. They are called in such a way
in RFC 7296 when authentication of IKE SA is defined (Section 2.15 of
RFC 7296). As result - both IKE_SA_INIT messages are included
into the blobs of data that are signed or MAC’ed by both peers.
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.
What you described is a common behavior in IKEv2 for negotiation of
support for an extension –
an initiator includes some notification in the request indicating that
it wishes to use an extension and
a responder includes the same notification in the response _only_ if
it sees it in the request.
The draft intentionally uses a slightly different approach that makes
it impossible for an attacker to
persuade peers that one of them does not support this extension in
case both support it.
The approach is that both initiator and responder _unconditionally_
include this notification
in their messages if they support this extension (major change in
behavior is for the responder –
it _always_ includes this notification in the response even if it was
not present in the request).
With this approach downgrade of this extension is not possible if both
peers support it (even if it is optional for them).
Indeed, if an attacker removes this notification from the IKE_SA_INIT
request, then responder will
send this notification in response anyway, but it will use old RFC 7296
logic for authentication.
The initiator will receive this notification and will think that both
peers support the new logic and will use it,
thus the SA will fail. The same will happen if the attacker does not
modify the request, but removes
this notification from the response. Note, that the attacker cannot
remove this notification from both request and response,
because in this case it have to forge both initiator and responder
signatures, which is beyond the preconditions of the attack –
it this case the attacker can do everything and no defense is possible.
Finally, a typo: "usese" => "uses"
Fixed, thank you.
Regards,
Valery.
Best,
Chris P.
On Thu, Jun 26, 2025 at 3:34 AM Valery Smyslov
<[email protected]<mailto:[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]<mailto:[email protected]>>
Sent: Wednesday, May 28, 2025 11:47 PM
To: [email protected]<mailto:[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]<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.
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]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
