Dear Meiling and Paul, Thanks the input text. Yes, absolutely, the support of IKE_INTERMEDIATE and IKEV2_FRAG should be indicated by the both peers before exchange the public key and ciphertext of FrodoKEM.
We will update our draft soon to make this clear. Happy new year, everyone! Cheers, Guilin 发件人：Paul Wouters <[email protected]<mailto:[email protected]>> 收件人：[email protected] <[email protected]<mailto:[email protected]>> 抄 送：Wang Guilin <[email protected]<mailto:[email protected]>>;ipsec <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>;smyslov.ietf <[email protected]<mailto:[email protected]>> 时 间：2025-12-31 21:35:39 主 题：Re: [IPsec] Re: FW: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt On Dec 31, 2025, at 01:21, [email protected]<mailto:[email protected]> wrote: For handling fragmentation after IKE_INIT_SA exchanges, the IKE_INTERMEDIATE exchanges [RFC9242] and IKE fragmentation mechanism [RFC7383] MUST be negotiated and supported for large exchange transmission between the two peers. In this way, large-sized PQ public key and ciphertext shall be transferred between them via IKE fragmentation, rather than IP fragmentation. This is illustrated in the example given in Fig. 1 by the two Notify Type messages, namely, N(IKEV2_FRAG_SUPPORTED) and N(INTERMEDIATE_EXCHANGE_SUPPORTED). More might need to be said since you might need to use a hybrid and start with a classical algorithm in IKE_SA_INIT to get ready to use fragmentation in the IKE_INTERMEDIATE exchanges where you can use FrodoKEM. I assume you cannot start frodokem in IKE_SA_INIT before the fragmentation support is available. Paul Best, Meiling ________________________________ [email protected]<mailto:[email protected]> From: Wang Guilin<mailto:[email protected]> Date: 2025-12-30 15:55 To: [email protected]<mailto:[email protected]>;Wang Guilin<mailto:[email protected]>; ipsec<mailto:[email protected]> CC: [email protected]<mailto:[email protected]>;smyslov.ietf<mailto:[email protected]> Subject: [IPsec] Re: FW: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt Hi, Meiling, Thanks for your review. 1. About the standardization status of FrodoKEM in ISO: As we know it is nearly finished, and it is likely to be published as ISO standard in 2026Q1. We shall cite the most recent document from the algorithm design team: https://frodokem.org/files/FrodoKEM_standard_proposal_20250929.pdf. 2. About [I-D.LBES25], as we know it is the same as the ISO standard proposal, but we can check further. Yes, we mistakenly marks this draft as a CFRG group document when we updated the reference. Thanks for spotting this. 3. For the fragmentation in IKE, this draft just follows RFC 9370, RFC 9242 and RFC 7383. If possible, you are welcome to input some text for this purpose. Cheers, Guilin From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Friday, 26 December 2025 12:43 am To: Wang Guilin <[email protected]<mailto:[email protected]>>; ipsec <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; smyslov.ietf <[email protected]<mailto:[email protected]>>; Wang Guilin <[email protected]<mailto:[email protected]>> Subject: Re: [IPsec] FW: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt Hi authors, I have reviewed the lasted version, and I have the following comments: 1, In section 3.2, FrodoKEM is based on ISO standards. I'm very curious if FrodoKEM has already been standardized by ISO? Or what stage currently at? the reference for FrodoKEM is dated to 2024, and the reference for I-D.LBES25 is dated to September 2025, have they made any recent changes? If so, it is recommended that the references be updated synchronously. in additon, the reference I-D.LBES25 claims to be a WG document, but I have found that the latest version is actually a personal draft. 2,Section3.3, Comparison to ML-KEM, due to the large size, FrodoKEM inevitably encounter fragment, the draft t only mentioned the trigger IKE fragmentation, However, there was no mention of how the fragmentation should be handled, just as a suggestion, providing additional descriptions for the fragmentation-processing. Best, Meiling Chen ________________________________ <mailto:[email protected]>[email protected]<mailto:[email protected]> From: Wang Guilin<mailto:[email protected]> Date: 2025-12-24 19:18 To: ipsec<mailto:[email protected]>;<mailto:[email protected]>[email protected]<mailto:[email protected]> CC: <mailto:[email protected]> [email protected]<mailto:[email protected]>;<mailto:[email protected]>[email protected]<mailto:[email protected]>;Wang Guilin<mailto:[email protected]> Subject: [IPsec] FW: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt Dear all, We have just updated our ikev2-frodo draft to version 03. All comments are welcome! In this draft, we have switched 4 variants of eFrodoKEM (ephemeral mode) to those of FrodoKEM (standard mode). The mains reasons are here: · IKEv2 [RFC 7296] does not require that the public keys for key exchange never repeat. · We have aligned with the authors of FrodoKEM draft in CFRG, and they also recommended us to use FrodoKEM (not eFrodoKEM) in IKEv2. Here is their helpful reply on Nov 9: “I think I would tend to agree with you that choosing the standard FrodoKEM variants is best suitable for your draft. The overhead is negligible and it is the default option now. We kept the eFrodoKEM variants (previously known as FrodoKEM variants) mostly for backwards compatibility of the standard.” The detailed explanation for this change is given in Section 3.2. At 124 meeting, Scott asked what the performance difference between AES and SHAKE variants. Now, experiments by one of our colleague show that AES variant with hardware acceleration is about 6 times faster than SHAKE variant without hardware acceleration. We are trying to get the number how SHAKE variant is faster than AES variant, if both have no hardware acceleration. It should be a few times. We will try to show these numbers a little later. Dear chairs, We think our draft is ready for the Group Adoption Call. It would be great if this can be considered after new year. If there is any aspect to improve our draft now, please let us know. Marry Christmas! Guilin, Leonie, and Valery. =================== A new version of Internet-Draft draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt has been successfully submitted by Guilin Wang and posted to the IETF repository. Name: draft-wang-ipsecme-hybrid-kem-ikev2-frodo Revision: 03 Title: Post-quantum Hybrid Key Exchange in IKEv2 with FrodoKEM Date: 2025-12-24 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.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-03.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-03 Abstract: Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework, which supports multiple key encapsulation mechanisms (KEMs) in 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 Cryptographically Relevant Quantum Computers(CRQCs). For this purpose, one or more post-quantum KEMs are usually performed in addition to the traditional (EC)DH key exchange. This draft specifies how the post-quantum KEM algorithm FrodoKEM is instantiated for 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 [W-D.K25]. ] From: Wang Guilin <<mailto:[email protected]>[email protected]<mailto:[email protected]>> Sent: Wednesday, 5 November 2025 12:08 am To: ipsec <<mailto:[email protected]>[email protected]<mailto:[email protected]>> Cc: <mailto:[email protected]> [email protected]<mailto:[email protected]>;<mailto:[email protected]>[email protected]<mailto:[email protected]>; Wang Guilin <<mailto:[email protected]>[email protected]<mailto:[email protected]>> Subject: [IPsec] Fw: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.txt Dear all, We just updated our FrodoKEM for IKEv2 draft to version 02. https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/ Here are the main changes: * Reduced code points from 6 in v01 to 4 now (revised Sections 3.3 and 6). • Explained why variants for both AES and SHAKE are necessary (revised Section 3.2). • Added Section 4.2 to describe the KEi(1) and KEr(1) payloads. • Also, Section 4.1 has been expanded to describe the main procedures of running FrodoKEM (or any PQ KEM) via ADDKE. Those changes have addressed all comments received from July 2025. Particular thanks go to Scott Fluhrer, Kev Kitchen, and Christopher Patton. The authors of this draft are applying for consideration of group adoption at or just after IETF 124 meeting, based on that the current version is quite mature, and also previous extensive discussions on FrodoKEM (as recalled below). - Summarized discussions available on my presentation slides at IETF 122https://datatracker.ietf.org/meeting/122/materials/slides-122-ipsecme-post-quantum-hybrid-key-exchange-in-the-ikev2-with-frodokem-00 - Over 20 discussions, most supportive, based on the recommendation from EU authorities. - The original discussion are also available athttps://mailarchive.ietf.org/arch/search/?q=Frodo&f_list=ipsec New comments and/or reviews are highly appreciated. Best wishes, Guili, Leonie, and Valey. ________________________________ From:<mailto:[email protected]>[email protected]<mailto:[email protected]> <<mailto:[email protected]>[email protected]<mailto:[email protected]>> Sent: Tuesday, November 4, 2025 8:47 PM To: Wang Guilin; Wang Guilin; Leonie Bruckert; Leonie Bruckert; Valery Smyslov Subject: New Version Notification for draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.txt A new version of Internet-Draft draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.txt has been successfully submitted by Guilin Wang and posted to the IETF repository. Name: draft-wang-ipsecme-hybrid-kem-ikev2-frodo Revision: 02 Title: Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM Date: 2025-11-04 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.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-02.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-02 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] To unsubscribe send an email to [email protected]
