Thanks, Panos! We'll take care of these: https://github.com/smyslov/ikev2-downgrade-prevention/issues/17
Chris P. On Fri, Feb 27, 2026 at 8:01 AM Kampanakis, Panos <kpanos= [email protected]> wrote: > 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 <[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]> 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] > 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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
