This comment I did not understand, can you clarify?
I think Chris understood: it's about whether there could be multiple ways to
arrive at the same concatenation.
There must not. RealMessage1 and RealMessage2 are always different in
IKEv2, because
in RealMessage1 Responder’s SPI is always 0, while in RealMessage2 it
cannot be 0.
In addition ZeroPrefix makes any authentication data block from RFC
7296 different compared to this construction,
since any IKE message (RealMessage1 or RealMessage2) starts from
Initiator’s SPI
that cannot be zero.
At least this is my understanding if I now got your concern right J
PR looks good, thanks!
Thank you!
Regards,
Valery.
Bas
§8. Refer to the section where you describe the downgrade attack.
Regards,
Valery.
On Thu, Feb 26, 2026 at 7:55 PM Christopher Patton
<[email protected]
<mailto:[email protected]> > wrote:
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] <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]
