Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments
I need CID 173 to be assigned to me as well since it will be covered
in the transcript changes even when that CID is currently in the
PDT-FILSFastSetup group. That group feels wrong in any case since this
comment is about the definition of the FrameData_n indexes in the
transcript and FILS is just one of the examples mentioned in the
comment.
- Jouni
On Mon, Sep 14, 2026 at 5:37 PM Jouni Malinen <jkmalinen@xxxxxxxxx> wrote:
>
> 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