Hi Guilin,
Hi, Valery,
Thanks a lot for the following comments:
"Note, that the original request and response with this notification are not
included into the AUTH calculation. But there is a requirement, that the new
request MUST contain exactly the same proposals as the original one. If we
assume that the responder always selects the strongest key exchange method
among proposed, then the attacker cannot fool it to select a weak one by
injecting INVALID_KE_PAYLOAD before genuine responder. "
The following rule pointed the above seems the crucial one to exclude
downgrading attack by just sending forged error messgaes: "the new request
MUST contain exactly the same proposals as the original one.". I do hope this
shall work well.
Yes, it should work if responder also has a policy to always select
the strongest KE among proposed (even at the cost of additional round trip).
However, I was wondering what the initiator will do if all KE methods proposed
in a request were rejected by the responder.
Then the connection won't succeed.
Does IKEv2 specify at least one specific KE method that is mandotary to be
implemented by all implentations both sides and proposed in every request?
There is RFC 8247.
Otherwise, if the initiator is unlucky for proposing a request which does not
include any KE method that is satisfied by the responder, then it just cannot
estabilsh an SA with the responder.
Correct.
Regards,
Valery.
Cheers,
Guilin
发件人：Valery Smyslov <[email protected] <mailto:[email protected]> >
收件人：Wang Guilin <[email protected] <mailto:[email protected]>
>;'ipsec' <[email protected] <mailto:[email protected]> >
抄 送：'Christopher Patton' <[email protected]
<mailto:[email protected]> >;'Wang Guilin'
<[email protected]
<mailto:[email protected]> >
时 间：2025-07-17 00:34:46
主 题：RE: [IPsec] IKEv2 downgrade prevention,
draft-smyslov-ipsecme-ikev2-downgrade-prevention
Hi Guilin,
thank you for your review. Please see inline.
Dear Valery and all,
Had a review on Valery’s new draft on IKEv2 downgrade prevention [1].
My short comments are: The downgrading attack is indeed valid, and the proposed
prevention seems working, though some complex situations may need to be
considered as well.
Detailed comments are given below.
Cheers,
Guilin
===============
Two main technical comments:
1. Sec 4: Step 4 assumes that the attacker A can break the selected "weak"
key exchange method in real time. But this assumption has not been listed in
the set of preconditions.
Hmm, I believe the precondition #2 mentions it:
2. Security policies for both initiator and responder must include
both "strong" and "weak" key exchange methods (with some
definition of "strong" and "weak") and the attacker must be able
to break "weak" key exchange methods in real time.
Perhaps it makes sense to mention this as a separate precondition.
2. The downgrading attack is valid, and the proposed prevention seems
working. However, it may need much more efforts to analyse if the prevention
does work securely in complex situations. For examples, the peers cannot finish
their IKE_SA_INIT exchange in two messages when there are one or more error
messages or notifications have been exchanged. In such situations, there may be
multiple versions of RealMessage1 and/or RealMessage2. So, how to calculate the
AUTH data, namely, InitiatorSignedOctets and ResponderSignedOctets, specified
in Sec 6? Just include the final successful RealMessage1 and RealMessage2 may
be not enough.
This problem also exists in core IKEv2. In particular, when the responder
responds
with INVALID_KE_PAYLOAD notification, the initiator restarts IKE_SA_INIT with a
different request.
Note, that the original request and response with this notification are not
included
into the AUTH calculation. But there is a requirement, that the new request
MUST contain
exactly the same proposals as the original one. If we assume that the responder
always
selects the strongest key exchange method among proposed, then the attacker
cannot fool it to select
a weak one by injecting INVALID_KE_PAYLOAD before genuine responder.
Even if it manages to force the initiator to send public key for a weak method
in KE payload, sensible responder will also reply with another
INVALID_KE_PAYLOAD insisting
on a stronger KE method. What an attacker can do - continue this ping-pong
with INVALID_KE_PAYLOAD, eventually preventing peers to connect.
The same requirement (that the IKE_SA_INIT request must be the same) applies to
response with COOKIE
notification (but see draft-smyslov-ipsecme-ikev2-cookie-revised for some
nuances).
All other error notifications in IKE_SA_INIT response will not result in
re-sending the request
(except for INVALID_MAJOR_VERSION, but we are not discussing changing IKE
version)
and IKE_SA_INIT will simply fail.
I agree that more analysis of various error conditions in IKE_SA_INIT will be
helpful,
but at first glance a downgrade attack is not possible (but note, that an
attacker
able to modify packets on the path can always prevent peers to establish a
connection).
Minor comments:
3. "These attacks are require the set of preconditions that are not
common, but still not unrealistic." => "The attack requires a set of
preconditions that that are not common, but still not unrealistic."
Hmm, we consider several similar attacks, thus plural form.
4. It may be better to use some letter to name the entities here for
improving readability. Say, I for the initiator, R for the responder, and A for
the attacker. Also, for messages, it may be helpful to say message 1, message
2, message 1', message 2' etc, where the last two messages refer those that
are modified by the attacker.
Will consider, thank you.
5. Sec. 4: The last part of “2)” for descripting the attack seems not
very clear: "Then this message is intercepted and re-injected without "strong"
key exchange methods.". By using the names the above, it can be described as
the following instead: “Then, the attacker A forwards the response from the
initiator I to the responder R. Here, this response from I without "strong "key
exchange methods. "
OK, I see your point.
6. Sec. 4: step “2)”, what is the SK_*? It seems that there is no this
symbol in IKEv2 [RFC 7296].
This is short for seven session keys SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, SK_pr.
7. Sec 5: "Thus, if at least one non-compromised key is used in the IKE SA
establishing, then any modification of the IKE_SA_INIT messages will be
detected." ==> "Thus, if at least one non-compromised key is used in the IKE
SA establishing, then any modification of the IKE_SA_INIT messages will be
detected by the peer whose long term authentication key is not compromised."
OK, will clarify.
Regards,
Valery.
[1] Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version
2 (IKEv2)
draft-smyslov-ipsecme-ikev2-downgrade-prevention-00
https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-downgrade-prevention/
From: Wang Guilin <[email protected]>
Sent: Friday, 11 July 2025 12:28 am
To: Christopher Patton <[email protected]>; Wang Guilin
<[email protected]>
Cc: ipsec <[email protected]>; ipsecme-chairs <[email protected]>;
Leonie.Bruckert <[email protected]>; smyslov.ietf
<[email protected]>; Wang Guilin <[email protected]>
Subject: RE: [IPsec] FW: New Version Notification for
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt
Hi, Chris,
Yes, the downgrading issue is very relevant. Thanks for your message and the
detailed links.
Happy to think more and coordinate with you and other experts here. It is very
halpful for reading discussions on this IKEv2 general issue in the past two
weeks.
Cheers,
Guilin
_____
Wang Guilin
Mobile: +65-86920345
Mail: [email protected] <mailto:[email protected]>
发件人：Christopher Patton <[email protected] <mailto:[email protected]> >
收件人：Wang Guilin <[email protected]
<mailto:[email protected]> >
抄 送：ipsec <[email protected] <mailto:[email protected]> >;ipsecme-chairs
<[email protected] <mailto:[email protected]> >;Leonie.Bruckert
<[email protected] <mailto:[email protected]>
>;smyslov.ietf <[email protected] <mailto:[email protected]> >;Wang
Guilin <[email protected] <mailto:[email protected]> >
时 间：2025-07-10 04:31:47
主 题：Re: [IPsec] FW: New Version Notification for
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt
Hi Guilin,
Just a heads up that this draft may be vulnerable to the attack described here:
https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-downgrade-prevention/
Note that the ML-KEM draft
(https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/) is
vulnerable in exactly the same manner, so not something specific to your draft.
Mitigations are being discussed here:
https://github.com/csosto-pk/pq-mlkem-ikev2/issues/5
It might make sense to coordinate.
Best,
Chris P.
On Tue, Jul 8, 2025 at 4:51 AM Wang Guilin
<[email protected] <mailto:[email protected]> >
wrote:
Dear all,
Our draft "Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM" has
been updated to v01. Here are the two main changes made, as a response to
comments received at 122 meeting:
* Restructured the draft.
* Reduced the point codes from 12 to 6 (eFrodoKEM).
Also, we would like to ask group adoption, based on the mostly positive
discussions in mailing list, which were summarized on my presentation slides at
IETF 122
https://datatracker.ietf.org/meeting/122/materials/slides-122-ipsecme-post-quantum-hybrid-key-exchange-in-the-ikev2-with-frodokem-00
The original discussion are also available at
https://mailarchive.ietf.org/arch/search/?q=Frodo
<https://mailarchive.ietf.org/arch/search/?q=Frodo&f_list=ipsec> &f_list=ipsec
Dear chairs,
We will appreciate if a time slot could be assigned for us to present this
draft at Mardid.
Thanks,
Guilin (On behalf of Leonie and Valery as well)
-----Original Message-----
From: [email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]> >
Sent: Monday, 7 July 2025 7:13 pm
To: Wang Guilin <[email protected] <mailto:[email protected]> >; Wang
Guilin <[email protected] <mailto:[email protected]> >; Leonie
Bruckert <[email protected] <mailto:[email protected]> >;
Leonie Bruckert <[email protected]
<mailto:[email protected]> >; Valery Smyslov <[email protected]
<mailto:[email protected]> >
Subject: New Version Notification for
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt
A new version of Internet-Draft
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt has been successfully
submitted by Guilin Wang and posted to the IETF repository.
Name: draft-wang-ipsecme-hybrid-kem-ikev2-frodo
Revision: 01
Title: Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM
Date: 2025-07-07
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt
Status:
https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/
HTML:
https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-wang-ipsecme-hybrid-kem-ikev2-frodo
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01
Abstract:
Multiple key exchanges in the Internet Key Exchange Protocol Version
2 (IKEv2) [RFC9370] specifies a framework that supports multiple key
encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol
Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to
derive the final shared secret keys for IPsec protocols. The primary
goal is to mitigate the "harvest now and decrypt later" threat posed
by cryptanalytically relevant quantum computers (CRQC). For this
purpose, usually one or more post-quantum KEMs are performed in
addition to the traditional (EC)DH key exchange. This draft
specifies how the post-quantum KEM FrodoKEM is instantiated in the
IKEv2 as an additional key exchange mechanism.
[EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as
the code points for ML-KEM has been considered in [I-D.KR24]. ]
The IETF Secretariat
_______________________________________________
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]
