Hi Bas, thank you for your comments. I created a PR that reflects most of your suggestions: https://github.com/smyslov/ikev2-downgrade-prevention/pull/19 Please also see inline/ Looks good to me. Nits. Abstract: "some kind" -> "particular" sound a bit better to my ear. Introduction: Perhaps use "SIGn-and-MAc (SIGMA)" as SIGMA protocol can be confused nowadays with the class to which Schnorr belongs. The introduction feels like it's missing a final sentence. Something like "In this document we'll first describe how authentication works now (§3); to which attack it's vulnerable (§4), ..." This is more in a tradition of academic papers J I personally don’t think this is needed, however I agree tat perhaps the Introduction is too short. Lacking the concrete text I leave it as is for now. §3. "Peers sign (or MAC) some blobs". Is blobs the standard terminology? RFC 7296 uses “block of data”, thus I changed to this term. For clarity I'd add "the initiator, but not the responder, authenticates the IKE_SA_INIT [...]" §4. What do you mean to say with 'for some definition of "strong" and "weak"'? Isn't the next sentence "the attacker must be able to break "weak" key exchang methods in real time" enough? §5. "aims to detect". Why "aims"? It does detect it. Why would you support the extension and not use it? I'd write something like "This document defines an extension that when supported by both peers prevents the downgrade attacks described in [...]. The peers achieve this by hashing in both sent and received messages when the extension is supported by both. This ensures that if both peers support the extension and at least [...]" I left the text as is for now, waiting for more comments. §6 Is there any potential confusion on how to split the concatenation RealMessage1 | RealMessage2 | Nonce*Data | MACedIDFor*? This comment I did not understand, can you clarify? §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]
