And in the other direction, I would request following CIDs to be
assigned to me: 114, 115, 125, 289, 344, 346, 365, 664, 665, 709, 742
(those are editorial comments that will likely result in conflicts
and/or extra work if handled separately).
I'd also note that the comment group PDT-MLDSMD11bn is likely going to
require coordination since it is also touching areas that are covered
in what I will be proposing for the Transcript group. I'm not sure it
would be appropriate for me to request those to be assigned to me
since there seems to be following the TTT approach. If that effort
does not move ahead, I'd likely address those couple of CIDs together
with the comments that are currently assigned to me.
- Jouni
On Mon, Sep 14, 2026 at 3:14 PM Jouni Malinen <jkmalinen@xxxxxxxxx> wrote:
>
> The following three CIDs feel more generic than what I'm planning on
> covering in a single document. For now, I think it would likely be
> best to assign these to the commenter or someone else who could
> volunteer to work on these while I focus on all the other comments in
> the transcript and PTK derivation comment groups.
>
> CID: 223
> Page/Line: 49.47
> Clause: 12.17.5
> Comment:
> For hybrid PQC profiles, the D1.0 specifies that the derived key
> includes both the classical DH shared secret and the ML-KEM shared
> secret. However, the protocol does not define an explicit
> peer-verifiable indication that all cryptographic components required
> by the negotiated security profile have completed and have been bound
> to the current authentication session. Parameter presence alone is not
> an explicit cryptographic proof of component completion.
> Proposed Change:
> Define a Hybrid Completion Verification value for PQC profiles
> containing more than one cryptographic component. The value shall be
> cryptographically derived from, or authenticated with a key derived
> from, all required shared secrets for the negotiated Security Profile
> and shall bind at least the Security Profile Number, the relevant
> transcript hash, and a session identifier. A peer shall verify the
> value before accepting the authentication/FT exchange as successfully
> completed.
> The commentor will bring a contribution to address this comment and
> provide more detaild solutions.
>
> CID: 225
> Page/Line: 49.18
> Clause: 12.17.3
> Comment:
> The PQC PASN exchanges may result in significantly higher computation
> and management-frame overhead than a classical PASN exchange. The D1.0
> does not define a protocol mechanism for binding or reusing a
> successfully established PQC PASN key for a subsequent association or
> key-management session, which can result in redundant PQC key
> establishment.
> Proposed Change:
> Define a PASN Key Binding indication and Session Identifier. A STA may
> include a Session Identifier and a Key-Reuse/Binding indication in a
> subsequent Association Request or other applicable security exchange
> to request that the previously established PQC PASN key be bound to
> that target session. The peer shall explicitly accept or reject the
> requested binding in the corresponding response. Specify cryptographic
> binding between the PASN transcript, peer identities, target session
> identifier and the derived key to prevent cross-session reuse.
> The commentor will bring a contribution to address this comment and
> provide more detaild solutions.
>
> CID: 743
> Page/Line: 34.44
> Clause: general
> Comment:
> Several handshakes were updated with new ephemeral key generation to
> enable the derivation of the DHss and MLKEMss values, i.e., generation
> of public/private keys and ML-KEM decapsulation and encapsulation
> keys. The text is currently not explicit whether a peer must generate
> a new ephemeral key pair on every retransmission of a handshake
> message. Note that this refers to retransmissions at the higher layer,
> e.g., when message 1 or 2 in the 4-way handshake is retransmitted
> using an increased EAPOL-Key Replay Counter. Note that for other
> aspects this is occasionally explicitly clarified, e.g., "Generates a
> new nonce SNonce, if no SNonce has yet been generated for this 4-way
> handshake."
> Proposed Change:
> Where appropriate, make it explicit that ephemeral key pairs only have
> to be generated once per handshake execution. I hope to find time to
> provide a more detailed resolution, direct help and positive/negative
> feedback are always welcome in the meantime.
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1