[IPsec] Re: WG Last Call: draft-ietf-ipsecme-ikev2-downgrade-prevention-01 (Ends 2026-03-02)

["Kampanakis, Panos" <[e-mail]>]

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.
- 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.
- 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./




From: Christopher Patton <cpatton=[e-mail]>
Sent: Thursday, February 26, 2026 1:55 PM
To: Tero Kivinen <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 [e-mail]<mailto:[e-mail]>
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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>