Hello, I have read through the draft and believe it is very close to completion. Section 5 can be improved slightly, as it is light on details with respect to the sentence "Thus, if at least one non-compromised key is used in the IKE SA establishing, then any modification of the IKE_SA_INIT messages will be detected." I think it would be worthwhile to provide details as to why this is the case from the perspective of the attack models outlined within the draft. I have included some suggested text below.
"In both attack models, it is necessary that the attacker forward the responder’s signed octets. Since the attacker is presumed to be incapable of forging a signature of the responder’s long-term private key, an attempt by the attacker to remove the responder’s commitment to this extension would invalidate the signature in the AUTH payload. Consequently, while an attacker could strip support for this extension from the initiator, it could not do so from the responder." I would recommend an explanation such as the above be placed before the sentence "In essence" in the final paragraph of section 5. I would also recommend the requirement in section 6 use normative language. Namely, s/"If the responder supports this extension then it also includes"/"If the responder supports this extension then it MUST include". This further enforces that it is the responder’s configuration and commitment that is pivotal to preventing this misbinding from an on-path attacker. Best, Keegan Dasilva Barbosa Canadian Centre for Cyber Security On Fri, Feb 27, 2026 at 12:24 PM Christopher Patton <cpatton= [email protected]> wrote: > 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] >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
