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
<[email protected]
<mailto:[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
<[email protected] <mailto:[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]
<mailto:[email protected]> >
Sent: Thursday, February 26, 2026 1:55 PM
To: Tero Kivinen <[email protected] <mailto:[email protected]> >
Cc: [email protected]
<mailto:[email protected]> ;
[email protected] <mailto:[email protected]> ; [email protected]
<mailto:[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]
<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]
