Hi Guilin thank you for your comments.
I created an issue https://github.com/smyslov/ikev2-downgrade-prevention/issues/24 and a PR https://github.com/smyslov/ikev2-downgrade-prevention/pull/23 Please also see inline. > I support the publication of this document. The update by itself is > important, and also the downgrade attacks > demonstrated are good examples for security research and standardization > practice. > > Below is my review with some technical and editorial comments. Hope they are > useful to improve the readability of > the specification. > > Cheers, > > Guilin > > ============= > Technical Comments > > Section 3. > In the end of this part, it may be good to point out whey the current > formation of AUTH_Data in IKEv2 it not really > secure, so the attacks in Section 4 is possible. In this way, the two > sections are linked more tightly. Here is some > text for reference: > "Here, the Initiator also authenticates the None from the responder to > prevent replay attack, a common practice in > authentication. But, this is unfortunately still not enough, as the downgrade > attacks shown in Section 5." We already have the sentence at the end of Section 3: Thus, each side authenticates only the initial message it has sent and not the initial message it has received. I believe this is the key reason for attack be possible. > Section 4. > > a) One or two diagrams for both attacks described in Section 4? The current > description is clear and easy to follow > for guys familiar with IKEv2 [RFC 7296], but may be not easy for the readers > who are not such familiar with > IKEv2. If one or two diagrams given, it will help those readers, I think. I'm not against diagrams, but for now fail to invent any that would be good for IKEv2 newcomers... > b) Precondition 1: "The attacker must be on the path" also means the > attacker is on live? To mount the attacks, > this is necessary, I think. Hmm, I think that the text "with the ability to intercept communications between the peers and to _modify_ their messages" (emphasized by me) implies that the attack is in real time, no? > c) When talking to attack 2, "In this case the attacker cannot change the > algorithms selected by the responder, ...". > This sentence seems not really accurate, as the main attack described above > is actually not about changing the > algorithms selected by the responder, but changing the pool of the algorithms > from which the responder can select > an algorithm. Changed to "In this case the attacker cannot change the set of algorithms from which the responder makes its choice". > d) It may be helpful to mention that attacker 2 is applicable for an insider > attacker A, who is an legitimate user just > like R (e.g, R's colleagues), but A is trying to mount attack 2 targeting I > and R as the victims. I agree that this is possible, but not sure how to describe the attack so that it looks plausible. In this case the initiator will try to connect to R, but then it will learn that it connected to A... It is strange if the initiator continues communication. With responders it is different - they are passive sides and can accept communication requests from any legitimate initiator. > ----------------------------- > Editorial Comments > > Section 4. > a) "the attack can be mount as follows" => "the attack can be mounted as > follows" > > b) "must include public key for a "weak" key exchange method. " => "must > include one public key for a "weak" key > exchange method. " > > c) "Instead, the attacker only needs to know the long-term authentication key > of some party one of the peers is > configured to communicate with. " => "Instead, the attacker only needs to > know the long-term authentication key of > some party with whom one of the peers is configured to communicate. " > > d) " if at least one non-compromised authentication key is used by the peers > in the protocol run" => " if at least one > key used by the peers is not compromised in the protocol run" ?? > > Section 7.1: > > "Note, that authentication of the IKE_INTERMEDIATE exchange includes ..." => > "Note that authentication of the > IKE_INTERMEDIATE exchange includes ..." or "Note: authentication of the > IKE_INTERMEDIATE exchange > includes ..." I used modern <aside> feature of xml2rfc. Regards, Valery. > ================ > > > -----Original Message----- > From: Tero Kivinen via Datatracker <[email protected]> > Sent: Tuesday, 17 February 2026 1:50 am > To: [email protected]; [email protected]; > [email protected] > Subject: [IPsec] WG Last Call: > draft-ietf-ipsecme-ikev2-downgrade-prevention-01 (Ends 2026-03-02) > > 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]
