Hello Valery, This PR with Guilin's additional contribution addresses my primary concern. I support the publication of this draft with this context included.
Best, Keegan Dasilva Barbosa Canadian Centre for Cyber Security On Mon, Mar 2, 2026 at 8:44 AM Valery Smyslov <[email protected]> wrote: > Hi Keegan, > > > > thank you for your comments. > > > > I created an issue > https://github.com/smyslov/ikev2-downgrade-prevention/issues/21 > > and a PR https://github.com/smyslov/ikev2-downgrade-prevention/pull/22 > > > > Please see also inline. > > > > 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 added slightly modified text. > > > 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. > > > > Well, here I disagree. There are different opinions on when to > use RFC2119 language (and in the past I received controversial advises from > ADs on this). > > So, for myself, I crafted a rule and try to follow it. The rule > is: RFC 2119 language should only be used when there is a choice for an > actor at some point of a protocol > > and that choice affects interoperability or security. Here we > define protocol in such a way, that there is no choice for an actor: if > extension is supported > > the initiator/responder includes notification. No options, no > choice, MUST is redundant (IMHO). > > > > Regards, > > Valery. > > > > 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]
