Dear Valery and all, Had a review on Valery’s new draft on IKEv2 downgrade prevention [1].
My short comments are: The downgrading attack is indeed valid, and the proposed prevention seems working, though some complex situations may need to be considered as well. Detailed comments are given below. Cheers, Guilin =============== Two main technical comments: 1. Sec 4: Step 4 assumes that the attacker A can break the selected "weak" key exchange method in real time. But this assumption has not been listed in the set of preconditions. 2. The downgrading attack is valid, and the proposed prevention seems working. However, it may need much more efforts to analyse if the prevention does work securely in complex situations. For examples, the peers cannot finish their IKE_SA_INIT exchange in two messages when there are one or more error messages or notifications have been exchanged. In such situations, there may be multiple versions of RealMessage1 and/or RealMessage2. So, how to calculate the AUTH data, namely, InitiatorSignedOctets and ResponderSignedOctets, specified in Sec 6? Just include the final successful RealMessage1 and RealMessage2 may be not enough. Minor comments: 1. "These attacks are require the set of preconditions that are not common, but still not unrealistic." => "The attack requires a set of preconditions that that are not common, but still not unrealistic." 2. It may be better to use some letter to name the entities here for improving readability. Say, I for the initiator, R for the responder, and A for the attacker. Also, for messages, it may be helpful to say message 1, message 2, message 1', message 2' etc, where the last two messages refer those that are modified by the attacker. 3. Sec. 4: The last part of “2)” for descripting the attack seems not very clear: "Then this message is intercepted and re-injected without "strong" key exchange methods.". By using the names the above, it can be described as the following instead: “Then, the attacker A forwards the response from the initiator I to the responder R. Here, this response from I without "strong "key exchange methods. " 4. Sec. 4: step “2)”, what is the SK_*? It seems that there is no this symbol in IKEv2 [RFC 7296]. 5. Sec 5: "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." ==> "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 by the peer whose long term authentication key is not compromised." [1] Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version 2 (IKEv2) draft-smyslov-ipsecme-ikev2-downgrade-prevention-00 https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-downgrade-prevention/ From: Wang Guilin <[email protected]> Sent: Friday, 11 July 2025 12:28 am To: Christopher Patton <[email protected]>; Wang Guilin <[email protected]> Cc: ipsec <[email protected]>; ipsecme-chairs <[email protected]>; Leonie.Bruckert <[email protected]>; smyslov.ietf <[email protected]>; Wang Guilin <[email protected]> Subject: RE: [IPsec] FW: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt Hi, Chris, Yes, the downgrading issue is very relevant. Thanks for your message and the detailed links. Happy to think more and coordinate with you and other experts here. It is very halpful for reading discussions on this IKEv2 general issue in the past two weeks. Cheers, Guilin ________________________________ Wang Guilin Mobile: +65-86920345 Mail: [email protected]<mailto:[email protected]> 发件人：Christopher Patton <[email protected]<mailto:[email protected]>> 收件人：Wang Guilin <[email protected]<mailto:[email protected]>> 抄 送：ipsec <[email protected]<mailto:[email protected]>>;ipsecme-chairs <[email protected]<mailto:[email protected]>>;Leonie.Bruckert <[email protected]<mailto:[email protected]>>;smyslov.ietf <[email protected]<mailto:[email protected]>>;Wang Guilin <[email protected]<mailto:[email protected]>> 时 间：2025-07-10 04:31:47 主 题：Re: [IPsec] FW: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt Hi Guilin, Just a heads up that this draft may be vulnerable to the attack described here: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-downgrade-prevention/ Note that the ML-KEM draft (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/) is vulnerable in exactly the same manner, so not something specific to your draft. Mitigations are being discussed here: https://github.com/csosto-pk/pq-mlkem-ikev2/issues/5 It might make sense to coordinate. Best, Chris P. On Tue, Jul 8, 2025 at 4:51 AM Wang Guilin <[email protected]<mailto:[email protected]>> wrote: Dear all, Our draft "Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM" has been updated to v01. Here are the two main changes made, as a response to comments received at 122 meeting: * Restructured the draft. * Reduced the point codes from 12 to 6 (eFrodoKEM). Also, we would like to ask group adoption, based on the mostly positive discussions in mailing list, which were summarized on my presentation slides at IETF 122 https://datatracker.ietf.org/meeting/122/materials/slides-122-ipsecme-post-quantum-hybrid-key-exchange-in-the-ikev2-with-frodokem-00 The original discussion are also available at https://mailarchive.ietf.org/arch/search/?q=Frodo&f_list=ipsec Dear chairs, We will appreciate if a time slot could be assigned for us to present this draft at Mardid. Thanks, Guilin (On behalf of Leonie and Valery as well) -----Original Message----- From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Monday, 7 July 2025 7:13 pm To: Wang Guilin <[email protected]<mailto:[email protected]>>; Wang Guilin <[email protected]<mailto:[email protected]>>; Leonie Bruckert <[email protected]<mailto:[email protected]>>; Leonie Bruckert <[email protected]<mailto:[email protected]>>; Valery Smyslov <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt A new version of Internet-Draft draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt has been successfully submitted by Guilin Wang and posted to the IETF repository. Name: draft-wang-ipsecme-hybrid-kem-ikev2-frodo Revision: 01 Title: Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM Date: 2025-07-07 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt Status: https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/ HTML: https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.html HTMLized: https://datatracker.ietf.org/doc/html/draft-wang-ipsecme-hybrid-kem-ikev2-frodo Diff: https://author-tools.ietf.org/iddiff?url2=draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01 Abstract: Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive the final shared secret keys for IPsec protocols. The primary goal is to mitigate the "harvest now and decrypt later" threat posed by cryptanalytically relevant quantum computers (CRQC). For this purpose, usually one or more post-quantum KEMs are performed in addition to the traditional (EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM is instantiated in the IKEv2 as an additional key exchange mechanism. [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as the code points for ML-KEM has been considered in [I-D.KR24]. ] The IETF Secretariat _______________________________________________ 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]
