HI Songbo, > Hi Valery, Deb, > > On the detection-mechanism point, I think Valery’s explanation is useful > and probably only needs a short paragraph to make the behavior explicit for > implementers. > > One possible wording: > > The mechanism defined in this document does not require a separate > downgrade-detection procedure. Instead, the additional initial-exchange > data is included in the input to the IKEv2 authentication calculation. When > a peer verifies the peer’s authentication data, a modification to the > protected initial messages is detected as an authentication failure. The > peer is not expected to distinguish this failure from other authentication > failures, such as use of an incorrect credential or a local configuration > mismatch.
Thank you for the proposed text. I slightly modified it as follows: Thus, there is no a separate downgrade-detection procedure. Instead, the additional initial-exchange data (the IKE_SA_INIT message received by a peer) is included into the input to the IKEv2 authentication calculation. Since we assume that at least one of the long-term authentication keys is not compromised, then, in case of any modifications to the initial messages, the peer verifying authentication data created using the non-compromised key will detect authentication failure. The peer is not expected to distinguish this failure from other authentication failures, such as the use of an incorrect credential or a local configuration mismatch. I've updated the PR: https://github.com/smyslov/ikev2-downgrade-prevention/pull/42 Regards, Valery. > The main thing I would want to preserve is that this is an > authentication-failure path, not a new diagnostic signal that > implementations have to expose differently. > > Best, > Songbo Bu > > On Mon, 25 May 2026 17:12:59 +0300, Valery Smyslov [email protected] wrote: > > Hi Deb, > > thank you for the review. Please see inline. > > Thank you for your work on this draft. I found it to be well written and > easy to read (and super nice to be able to read a technical draft that I > understand!). > > I have a few comments that I’d like you to address: > > Section 1, para 2: Perhaps consider adding a phrase in the middle of this > sentence to say what the goal of this specification is: ‘…the data to be > authenticated in IKEv2 to prevent particular downgrade attacks, and > thus.....’ [nothing else in the intro gives even a hint of the plan] > > Done. > > Section 4: Consider making two subsections, one for each attack type, just > to add clarity. > > I’m a bit unsure whether this would help. First, the attacks are almost > identical, with very minor difference. > > The prerequisites and the impact are different, but the attack steps are > the same and for this reason > > only KCI attack is described in full details. Then, frankly we are not sure > that this list of two attacks > > is exhaustive (and thus use “at least two attacks” wordings). Putting them > into subsections > > will implicitly indicate that no other attacks are known. > > I’d rather hear from Chris and others whether this change is needed _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
