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." 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. 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. 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. 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. ----------------------------- 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 ..." ================ -----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]
