Hi, all, I support to publish draft-ietf-emu-pqc-eapaka, though the authors may consider to update v02 for a new version, for addressing comments given below.
(PS. Due to similarity of the two documents, I shall be able to complete my review on draft-ietf-emu-hybrid-pqc-eapaka tomorrow.) Cheer, Guilin =========================== Review on https://www.ietf.org/archive/id/draft-ietf-emu-pqc-eapaka-02.html Date: 18/7/2026 Reviewer: Guilin Wang -------------------------------------------- Main contributions: - Section 7: A native attribute-level fragmentation mechanism is specified to address potential over-sized transportation of related attributes for enabling PQ KEMs, which is similar to the lock-step acknowledgment model used by EAP-TLS [RFC2716]. (I have a main comment below on this mechanism to check if a more efficient method is possible) . - Sections 6 and 9: Defines or updates three attributes AT_PUB_KEM, AT_KEM_CT, and AT_KDF_FS (though the detailed format for AT_KDF_FS not given yet). - Sections 8: Protocol call flow and key derivation details to run PQ KEM for achieving forward security again CRQC. ------------------------------------------- Main Comments: - On the attribute-level fragmentation mechanism defined in Section 7: It seems possible (and better?) to add one field or two fields for identifying the order of one Fragmentation attribute, like the 5th fragmentation out of total 10, in The Fragmentation attribute format specified in Section 7.1. This may become much more efficient to deal with one specific Fragmentation attribute lost. It may also allow for confirming multiple fragmentations. For example, one A sends all 10 fragmentations consecutively, B just replies with 9 to indicate the first 9 fragmentations have been received up to now, but the last fragmentation (#10) has not been received yet. The current lock-step acknowledgment model seems very strict and less efficient, I think. It works like this: send one fragmentation => confirm receipt of it => send the next ... Section 7 says "The receiver MUST reassemble attribute fragments strictly in the order received and MUST NOT process the fragmented attribute until all fragments have been successfully received and validated." - Do not see the definition for AT_KDF_FS, but this is very important is this document. So I suggest add Section 9.3 to define the format of AT_KDF_FS, as did for AT_PUB_KEM and AT_KEM_CT in Sections 9.1 and 9.2. Section 6 mentions "The AT_KDF_FS attribute is updated to indicate the PQC KEM for generating the Master Key MK_PQ_SHARED_SECRET." - References need to be updated: details for 4 references are listed below. There may be more. ------------------------------------------- Minor comments Section 1. "This prevents an attacker who has gained access to the long term key from obtaining session keys established in the past, assuming these have been properly deleted." That session keys have been deleted or not is an operation issue. It does not really related to forward security. Forward security concerns if an attacker can just eavesdrop related info sent in sessions, later compromise the session key and then decrypt ciphertext to get data. Terms: PQ-KEM => PQ KEM. This is better, I think. "EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions" Why cannot prevent active attacks? " ... this document proposes a PQ-KEM for achieving perfect forward secrecy in EAP-AKA'." => "... this document proposes a PQ-KEM for achieving perfect forward secrecy in EAP-AKA' via replacing ECDHE by PQ-KEM." "As these algorithms are secure against both quantum and classical computer ... " => "As these algorithms are designed to be secure against both quantum and classical computer ..." Section 3: "Asymmetric Traditional Algorithm" is called "Traditional asymmetric cryptographic algorithm" in RFC 9794. Better to cite the definition from RFC 9794, though you may use "Asymmetric Traditional Algorithm" as a shorter name. Similar comment on "Post-Quantum Algorithm" in this document via "Post-quantum asymmetric cryptographic algorithm" in RFC 9794: Section 4. "The server asks the AD to run ..": Full name of AD? "the AT_KDF_FS(carries other FS related parameters)."=> "the AT_KDF_FS (carries other FS related parameters)." (to add a space) Section 5 Both PQ-KEM and PQ KEM appears. => PQ KEM. (PQ KEM used once and PQC KEM none in RFC 9794) Section 6 "We suggest the following changes and enhancements:" => "This document specifies the following changes and enhancements to enable PQ KEMs in EAP-AKA prime:" Section 7.1 "The total length of the attribute in octets is obtained by multiplying this field by 4." => "The total length of the Fragmentation attribute in octets is obtained by multiplying this field by 4." Section 8.2 "only an active attacker could have determined the generated session keys": Do not understand this claim. By assuming PQ KEM is secure, even an active attacker cannot get the sessions keys. This is the aim of the current specification. Right? Section 8.3 Aligning with the syntax gave in Section 4, suggest the following changes: "sk, pk = kemKeyGen()" => (sk, pk) = kemKeyGen() "ct, ss = kemEncaps(pk)" => (ct, ss) = kemEncaps(pk) "if the peer also supports the Forward secrecy" => if the peer also supports the forward secrecy "The server will use the ct and PQC KEM private key sk to generate shared secret" => The server will use the ct and PQC KEM private key sk to decansulate shared secret: "The generated ss" => The decapsulated ss "(line 2 of ML-KEM.Encaps algorithm in [FIPS203]).": Also give the specific Algorithm no. I will be more helpful, IMHO. Section 9.1 "AT_PUB_KEM: This is set to TBA1 BY IANA." => "AT_PUB_KEM: This is set to TBA1 BY IANA." "Length: A 2-byte unsigned integer indicating ..." => "Length: A 2-byte unsigned integer indicating ..." "is 1 byte.The ..." => "is 1 byte. The ..." "Value:": Do not see why the meaning of "Value" needs to be expressed in a diagram, rather than in text. Section 9.2 The similar comments gave the apply to Section 9.2 for AT_KEM_CT as well. Section 12 Suggest also give a table for the three new Attribute Type values (TBA1, TBA2, and TBA3) from IANA for AT_PUB_KEM, AT_KEM_CT, and AT_FRAGMENT, as did for the "EAP-AKA' AT_KDF_FS Key Derivation Function Values" for three variants of ML-KEMs. References: [I-D.ietf-pquip-pqt-hybrid-terminology] => RFC 9794 [I-D.ietf-tls-hybrid-design] => RFC 9954 [I-D.draft-ar-emu-pqc-eapaka], 16 March 2025 => draft-ietf-emu-hybrid-pqc-eapaka-01, 2026-06-19 [I-D.ietf-pquip-pqc-engineers], draft-ietf-pquip-pqc-engineers-14, 25 August 2025 => RFC 9958 (Post-Quantum Cryptography for Engineers), 2026-06-18 ==================== -----Original Message----- From: Wang Guilin <[email protected]> Sent: Tuesday, 14 July 2026 4:34 pm To: Peter Yee <[email protected]>; [email protected] Cc: Wang Guilin <[email protected]> Subject: RE: [Emu] Re: WGLC for draft-ietf-emu-pqc-eapaka and draft-ietf-emu-hybrid-pqc-eapaka I am also planning to review these two drafts (I did read them a while ago but have not submitted reviews). But this week too busy for preparing presentation slides etc before 126 meeting. I will try to do it by Sunday. Cheers, Guilin -----Original Message----- From: Peter Yee <[email protected]> Sent: Wednesday, 8 July 2026 2:07 am To: [email protected] Subject: [Emu] Re: WGLC for draft-ietf-emu-pqc-eapaka and draft-ietf-emu-hybrid-pqc-eapaka I need your help. The WGLC on these two drafts has expired. No one spoke up in favor of (or for that matter against) the documents. Tiru and Aritra have patiently worked on them. Could I get some volunteers to read through the drafts and render their thoughts? They are 21 and 13 pages, respectively. If I don’t get enough inputs for the WGLC, I’m going to have to rule that we don’t have consensus to advance them via the EMU WG, which would be a shame. Thank you. -Peter > On Jun 19, 2026, at 7:58 PM, [email protected] wrote: > > The discussion of these documents has been relatively quiet, but > reviews to the mailing list and comments during IETF meetings have > been addressed by the authors. Now the real proof of the pudding will > be whether the WG feels these documents are ready to advance. So, I > have placed both in WGLC that will end prior to the upcoming Vienna meeting. > > I would really like to see robust responses on whether these > documents are ready to advance given the relative dearth of discussion > following their adoption. There's certainly a need for PQC versions of > EAP mechanisms, so if you believe these documents embody the right > responses for EAP-AKA' (FS), please make your voice heard by sending a > message to the mailing list and detailing why they are ready to move > forward. Conversely, if you think they are not ready, that's useful > input as well, especially when actionable input is provided. > > Thank you in advance for your time and input. > > -Peter > > > > _______________________________________________ > Emu mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
