Hi Panos,
thank you for your comments. I created a PR:
https://github.com/smyslov/ikev2-downgrade-prevention/pull/20
and Chris already created an issue:
https://github.com/smyslov/ikev2-downgrade-prevention/issues/17
Few comments inline:
Hi Chris,
I think it is ready, but I have some nits/suggestions:
- s/ that are not common, but still not unrealistic/ that are not common, but
still plausible/
- s/ break authentication algorithm used by one of the peers in real time/
break the authentication algorithm used by one of the peers in real time/
- s/ has a long-term authentication key for the responder./ has the responder’s
long-term authentication key./
- s/ authentication key of initiator A./ authentication key of a different
initiator, A./
- Last paragraph of section 4. Mention that this attack used to be less
relevant when cryptographic algorithms were considered secure or insecure
because peers would disable the insecure ones and not negotiate them. But now
with any migration where algorithms co-exist and peers do not know if their
peer supports the “strong” algorithm, it becomes more relevant. Or something to
that effect. You mention it in Security Consideration, but I think it is
important to be in the motivation too.
I propose a text:
This attack used to be less relevant when cryptographic algorithms
were considered secure or insecure because peers would disable the
insecure ones and not negotiate them. With migration to PQ crypto
both the KCI and identity misbinding attacks can also be mounted on
the hybrid post-quantum key exchange defined in [RFC9370], where an
attacker able to break traditional key exchange method (e.g. by means
of a quantum computer) prevents peers from executing additional
quantum resistant key exchange method(s). This makes this attack
more relevant during migration to PQ crypto.
- s/ at least one non-compromised authentication key is used by the peers/ at
least one peer’s authentication key is not compromised/
- s/ then the protocol runs as defined in [RFC7296
<https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-01.html#RFC7296>
]./ then the IKEv2 negotiation runs as defined in [RFC7296
<https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-01.html#RFC7296>
].
- s/ in the IKE SA establishing,/ in the IKE SA establishment,/
- For clarity, add a sentence in Section 7 to mention that subsequent messages
like CREATE_CHILD_SA IKE_FOLLOW_UP do not apply to the new signed octets
because they follow IKE_AUTH.
Hmm, I’m not sure this is needed. Obviously, only IKE_AUTH is affected
(and GSA_AUTH for G-IKEv2).
- s/ It is therefore necessary for each of the peers to mandate the use of a
pre-shared key (and abort the connection if negotiation fails)./ It is
therefore necessary for peers configured to use a pre-shared key with another
peer to abort the connection if the peer does not negotiate the USE_PPK
extension./
To be precise we should also mention USE_PPK_ALT, so the text becomes
less concise… I didn’t make any changes waiting for more comments..
Regards,
Valery.
From: Christopher Patton <[email protected]>
Sent: Thursday, February 26, 2026 1:55 PM
To: Tero Kivinen <[email protected]>
Cc: [email protected]; [email protected];
[email protected]
Subject: [EXTERNAL] [IPsec] Re: WG Last Call:
draft-ietf-ipsecme-ikev2-downgrade-prevention-01 (Ends 2026-03-02)
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
Hi all, I just wanted to add that we implemented this feature in our internal
implementation of IKEv2 and have confirmed interop with strongswan's
experimental branch:
git clone --depth 1 --branch downgrade-prevention
https://github.com/strongswan/strongswan.git
One thing we noticed is that the draft doesn't explicitly specify how to handle
a malformed IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification (i.e., one that has a
non-empty payload, a non-zero Protocol ID, or a non-zero SPI Size [1]). Our
responder handles this case by sending an INVALID_SYNTAX error. (We don't
implement an initiator.) My understanding is that this behavior is allowed by
IKEv2, but other behaviors are allowed as well. If my understanding is correct,
then I don't see a need to make the behavior explicit.
Apart from that, I have no more changes for the WG to consider and I think this
is ready to go. We look forward to getting a codepoint!
Best,
Chris P.
[1]
https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-01.html#section-6-1
On Mon, Feb 16, 2026 at 9:49 AM Tero Kivinen via Datatracker <[email protected]
<mailto:[email protected]> > wrote:
This message starts a WG Last Call for:
draft-ietf-ipsecme-ikev2-downgrade-prevention-01
This Working Group Last Call ends on 2026-03-02
Abstract:
This document describes an extension to the Internet Key Exchange
protocol version 2 (IKEv2) that aims to prevent some kinds of
downgrade attacks on this protocol by having the peers confirm they
have participated in the same conversation.
File can be retrieved from:
Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [email protected]
<mailto:[email protected]>
in copy. Objections should be explained and suggestions to resolve them are
highly appreciated.
Authors, and WG participants in general, are reminded of the Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be
found at [3].
Thank you.
[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-downgrade-prevention-01
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-downgrade-prevention-01
_______________________________________________
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]
