Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments
We'll go through 1870r1 shortly (with minor edits to proposed comment
resolutions and changing tagging after 1870r0). We can discuss what to
do with some of the comments that I did not yet propose resolutions
for, but my current feeling is either to assign them to someone else
or expect me to propose many of them to rejected since I'm not
convinced I would support the proposed direction. These comments are
not really on transcript or PTK derivation, but on PMKID derivation or
moving description of PQC things in general to different location. As
such, I think they should be covered in a separate document regardless
of who they are assigned to.
These are the relevant comments:
CID: 391, 392, 393, 394, 395. 410, 411
CID: 391
Page/Line: 31.20
Clause: 12.7.1.3
Comment:
The content references in 12.12.10 is a requirement, not a constraint.
The table should be addred to this clause.
Proposed Change:
Move the table in 12.12.10 to 12.17.5 and update the reference.
TODO
CID: 392
Page/Line: 31.34
Clause: 12.7.1.3
Comment:
If there is a specific PMKID, PTK derivation for PQC protocols, then
they should be defined in the PQC subclause.
Proposed Change:
For PQC AKMs, add a reference to 12.17.5. Move the PMKID definition to
12.17.5. The commenter is willing to help clean-up this text.
TODO
CID: 393
Page/Line: 31.61
Clause: 12.7.1.3
Comment:
IF PTK derivation for PQC is defined in 12.17.5, reference this clause
in 9.4.2.23 (RSNE), and add a note in 12.7.1.3 and 12.7.1.6.
Proposed Change:
Clean-up the changes in this clause reference to 12.17.5. Clean-up the
reference in 9.4.2.23. The commenter is willing to help clean-up this
text.
TODO
CID: 394
Page/Line: 32.10
Clause: 12.7.1.6.3
Comment:
Similar to the 12.7.1.3, Key derivation for PQC should be in the PQC
Security framework clause.
If there are client privacy requirements related to PQC, they should
be in Clause 12.7.5.
Proposed Change:
Clean-up the changes in this clause reference to 12.17.5. The
commenter is willing to help clean-up this text.
TODO
CID: 395
Page/Line: 32.24
Clause: 12.7.1.6.5
Comment:
Key Derivation for PQC procools are part of the PQC Security framework
and should be moved to Clause 12.7.5.
Proposed Change:
Clean-up the changes in this clause reference to 12.17.5. The
commenter is willing to help clean-up this text.
TODO
CID: 410
Page/Line: 49.22
Clause: 12.7.3
Comment:
The PQC aspects for the 802.1X protocol and the instantiattion of the
key hierarchy should be included within this sub-clause or under this
subclause.
Proposed Change:
Describe the PQC-specific requirements for 802.1X for the
authentication protocol as well as the PMK and PTK derivation. It's OK
to refer to other sub-clauses. The commenter is willing to help
restructure this description.
TODO
CID: 411
Page/Line: 49.22
Clause: 12.7.3
Comment:
The PQC aspects for the FT protocol and the instantiation of the key
hierarchy should be included within this sub-clause or under this
subclause.
Proposed Change:
Describe the PQC-specific requirements for FT for the authentication
protocol as well as the PMK and PTK derivation. It's OK to refer to
other sub-clauses. The commenter is willing to help restructure this
description.
TODO
On Tue, Sep 15, 2026 at 11:34 AM Jouni Malinen <jkmalinen@xxxxxxxxx> wrote:
>
> I've now posted an initial version of the document that discusses
> these comments and proposes resolutions to them
> https://mentor.ieee.org/802.11/dcn/26/11-26-1870-00-00bt-transcript-and-ptk-derivation-comments-on-p802-11bt-d1-0.docx
>
> This rev 0 is not yet complete, i.e., it does not address changes
> requested in a couple of the restructuring comments and it does not
> have proposed resolution prepared for all comments even when the
> redline changes address most of the comments. I wanted to make this
> version available now so that there is at least a small chance for
> some offline review before this gets presented. Any feedback is
> welcome now or during the presentation.
>
> I would like to request agenda time to go through the document (likely
> a bit more complete r1 assuming I find enough time to prepare that) in
> the TGbt Tue PM1 slot so that we can try to determine whether the TG
> supports the proposed direction and have some time available for
> additional offline review and editing work so this the document would
> be in acceptable form to be motioned this week.
>
> - 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