[Emu] Re: WGLC for draft-ietf-emu-pqc-eapaka and draft-ietf-emu-hybrid-pqc-eapaka

[Wang Guilin <[e-mail]>]

Hi, all,

Below is my review on [draft-ietf-emu-hybrid-pqc-eapaka]. My suggestion is DISUSS. 

The main reason is that there is a simpler way to enable hybrid KEMs in EAP-AKA', by just registering a new hybrid KEM as a new PQ KEM. I think this is also the main purpose of [I-D.ietf-hpke-pq] and [I-D.irtf-cfrg-hybrid-kems]. Namely, by taking a hybrid KEM as a composite PQ KEM, just following [draft-ietf-emu-pqc-eapaka] will be enough to run a hybrid KEM. This is a big issue, and I do think we should choose this approach, without introducing AT_PUB_HYBRID attribute at all, which is done in this document. 

Other minor issues are quite easy to address, I think. 

Cheer, 

Guilin
===========================
Review on [draft-ietf-emu-hybrid-pqc-eapaka]
https://www.ietf.org/archive/id/draft-ietf-emu-hybrid-pqc-eapaka-01.html
Date: 20/7/2026
Reviewer: Guilin Wang
--------------------------------------------
Main contributions: 

- Sections 7: Steps to derive key materials.
- Section 8: Defines/updates the AT_PUB_HYBRID attribute to run hybrid KEMs (though the detailed format for AT_KDF_FS not given yet). 
- Section 10: Ask to registers two concrete hybrid KEMs with ML-KEM-768.
-------------------------------------------
Main Comments: 

1) As mentioned in message body, I think the main issue is that by treading a hybrid KEMs as a new PQ KEM, without introducing AT_PUB_HYBRID, just registering a new algorithm its use in EAP-AKA' will be able to run it via using the AT_PUB_KEM specified in [I-D.ietf-emu-pqc-eapaka]. This is a simple and systematic way, which leaves the details about how to hybridize ECDH and PQ KEM to crypto engineering level, not to EAP-AKA level. Of course, some helpful about treading a hybrid KEMs as a composite is helpful to readers. 

2) Suggest just use one of [I-D.ietf-hpke-pq] and [I-D.irtf-cfrg-hybrid-kems] as a normative reference for how KEMs are hybridized here. 

3). Tell a little more on the relationship of this document and [I-D.ietf-emu-pqc-eapaka] in Introduction. Technically, this seems straightforward. 

4) References need to be updated. See details below. 
--------------------------------------------
Minor Comments

Abstract: 
"If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'." => "If the adversary has also obtained knowledge of the long-term key, it could compromise session keys generated as part of the authentication run in EAP-AKA'."

Here "also" should just means for the compromise of the long-term key, as the compromise of ephemeral key has been mentioned in previous sentence due to CRQCs.  

"Q/T Hybrid": Better to say the full name, as this is the first appearance of "Q/T Hybrid". 

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. EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against future sessions."

=> "This prevents an attacker who has gained access to the long term key from obtaining session keys established in the past. EAP-AKA' FS mitigates passive attacks (e.g., large scale pervasive monitoring) against past sessions."

Here, I suggest delete ", assuming these have been properly deleted" as it may confuse readers to conclude that compromising past session keys by attackers is due to these keys being not deleted. Also, I think the goal of forward security is actually to prevent such attacks against past sessions, not future sessions. For future sessions, once an attacker in possession of the long-term key, it can do a lot more than passive attacks already. So, still talking about security against passive attacks is not really important.

"modern digital cryptography" => "modern cryptography"

"This specification defines HPKE [I-D.ietf-hpke-pq] [I-D.irtf-cfrg-hybrid-kems] for use with EAP-AKA' FS." => "This specification defines the use of HPKE [I-D.ietf-hpke-pq] [I-D.irtf-cfrg-hybrid-kems] with EAP-AKA' FS. " 

"HPKE" => full name of HPKE as well. 

Section 3.

"Elliptic Curve Diffie-Hellman Ephemeral Static" reads a little weird, better to say "Elliptic Curve Diffie-Hellman Ephemeral or Static"?

"Examples of PQC key exchange algorithms include Kyber." => better to replace Kyber by ML-KEM and add a reference. 

Section 4.

"In EAP-AKA', The authentication vector (AV)" => "In EAP-AKA', the authentication vector (AV)"

"The server asks the AD to run": give the full name of AD and tell its function? 

"the AT_KDF_FS(carries other FS related parameters). " => "the AT_KDF_FS (carries other FS related parameters)." 

"Both of these might be ignored of USIM doesn’t support the Forward Secrecy extension." => Both of these might be ignored by a USIM that doesn’t support the Forward Secrecy extension." 

 "a Forward extension" => "a Forward Security extension"

"AT_PUB_ECDHE and MAC" => "AT_PUB_ECDHE and AT_MAC"

"The shared key will be generated both in the peer and the server" => "The shared key will be generated both by the peer and the server"

Section 5. 

PQC KEM, PQ KEMs (in the reference of [I-D.ietf-emu-pqc-eapaka]) => PQ KEM, as the same term used in https://www.ietf.org/archive/id/draft-ietf-emu-pqc-eapaka-02.html

"The AT_PUB_HYBRID attribute will carry the encapsulated key, which is formed by concatenating the encapsulated key (enc) from the traditional KEM algorithm and the ciphertext (ct) from the PQC KEM Encapsulation function from the EAP peer.": This part confuses me: Using enc to denote the encapsulated key. It seems better to separately describe the content of the AT_PUB_HYBRID in two cases: The peer and the server. 

"the PQC KEM Encapsulation function" => "the PQ KEM encapsulation function"

Section 6. 

About the details of the message fragmentation and reassembly, ok to referee to [I-D.ietf-emu-pqc-eapaka]. But, it is better to say a few sentence why this is necessary, and what the features of the mechanism introduced in [I-D.ietf-emu-pqc-eapaka]. 

Section 7.1

" to the peer In the message " =>  " to the peer. In the message " 

Section 7.2
"the PQC KEM Public key(pq_PK)" => " the PQ KEM Public key (pq_PK)"

"the peer also supports the Forward secrecy, peer will invoke Encapsulate using" => "the peer also supports forward secrecy, peer will invoke Encapsulate (?)using". Also, I did not find a function called "Encapsulate" in [I-D.irtf-cfrg-hybrid-kems] (either v08 or the current v12)

Similar comment on "Decapsulate", mentioned in "The generated ss from Decapsulate ..."

"HYBRID_SHARED_SECRET, ct = Encapsulate(pKR)" => "(HYBRID_SHARED_SECRET, ct) = Encapsulate(pkR)" or "HYBRID_SHARED_SECRET | ct = Encapsulate(pkR)" 

In this section, ss has been used to denote HYBRID_SHARED_SECRET. So, it seems no need to replace HYBRID_SHARED_SECRET by ss in the formula here. 

Section 8

"AT_PUB_HYBID:

This is set to TBA1 BY IANA." => "AT_PUB_HYBID: This is set to TBA1 BY IANA."

"Reserved:

A 1-byte field reserved for future use. Including ..." => "Reserved: A 1-byte field reserved for future use. Including ..."

"Length:

A 2-byte unsigned integer indicating ..." => "Length: A 2-byte unsigned integer indicating ..."

Section 9. 

"The overall Hybrid scheme needs to be IND-CCA2 robust; ..." => "The overall hybrid scheme needs to be IND-CCA2 robust; ..."

Section 10. 

In the Table here, "KDF(SHA3-256)" and "KDF(HKDF-SHA-256)' are not in the same format. Make sure they are right according to [I-D.irtf-cfrg-hybrid-kems] or [I-D.ietf-hpke-pq]. 

TBA1 for AT_PUB_HYBRID should be clearly lised here as well, I think. 

References:
[I-D.ietf-pquip-pqt-hybrid-terminology] => RFC 9794

[I-D.ietf-hpke-pq], 6 November 2025 => draft-ietf-hpke-pq-05, 2026-07-06

[I-D.irtf-cfrg-hybrid-kems]: draft-irtf-cfrg-hybrid-kems-08, 27 January 2026 => draft-irtf-cfrg-hybrid-kems-12, 2026-07-08
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hybrid-kems/

[I-D.ietf-pquip-pqc-engineers], draft-ietf-pquip-pqc-engineers-14, 25 August 2025 => RFC 9958 (Post-Quantum Cryptography for Engineers), 2026-06-1

[I-D.ietf-emu-pqc-eapaka] => version 2 now or even 3 soon. 

[I-D.draft-ar-emu-pqc-eapaka], 16 March 2025 => draft-ietf-emu-hybrid-pqc-eapaka-01, 2026-06-19
----------------------------------

-----Original Message-----
From: Wang Guilin <[e-mail]> 
Sent: Saturday, 18 July 2026 11:26 pm
To: Peter Yee <[e-mail]>; [e-mail]
Cc: Wang Guilin <[e-mail]>
Subject: RE: [Emu] Re: WGLC for draft-ietf-emu-pqc-eapaka and draft-ietf-emu-hybrid-pqc-eapaka

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 <[e-mail]>
Sent: Tuesday, 14 July 2026 4:34 pm
To: Peter Yee <[e-mail]>; [e-mail]
Cc: Wang Guilin <[e-mail]>
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 <[e-mail]>
Sent: Wednesday, 8 July 2026 2:07 am
To: [e-mail]
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, [e-mail] 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

_______________________________________________
Emu mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]