[STDS-802-11-TGBT] Let's behave professionally

You said, “you can implement a similar design as proposed in 26/1202r4 and 26/1203r4.” But I don’t want to. I want to do something more efficient and cleaner. That doesn’t mean I’m shooting at you or blaming you for anything. I just am refusing to follow your suggestion because I think I have a better technical solution.

If you’d like to focus on technical discussion then why are you saying, “Stephen/Robert, I need your help.” How can they help you focus on technical issues?

But let’s focus on technical issues. If you want every exchange that uses profile 1, 2, or 3 to generate “DHss || MLKEMss” then provide a valid technical justification. And explain why what I’m doing is not acceptable.

Don’t try to impose unnecessary constraints on work in this TG. And please consider solutions that are more efficient than what you propose.

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Please don't shoot at me. Please don't blame me. Once you did, I don't know how to focus on the technical discussion in the reflector.

From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>

To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>;

Date: 2026年09月16日 15:29

Subject: Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments

Hi 杨志杰10343608,

Yes, you’re right that I could implement a design similar to 26/1204r4 and 26/1203r4. But why? Why do additional messages and generate additional keying material if it’s not necessary? It’s a waste of time and effort. I would rather do something clean and efficient. And I don’t have a problem with using profiles 1, 2, and 3 with the PTK derivation changes Jouni is proposing.

I think a better solution would be for you to implement a design similar to 11-26/0089r7 and 11-26/0546r6, and 11-26/0547r3, and 11-26/0545r3. It’s much more efficient and uses the general purpose PTK derivation. And it isn’t necessary to define new profiles. Although 11-26/0547r3 does define new profiles because it also defines the use of Classic McEliese as a crypto system in addition to ML-KEM—please see the changes to 9.4.2.369 and 12.12.10 that add such support.

You may not want to discuss “other PQC schemes” in this thread but you started it by saying, “In fact, if the DHss||MLKEMss is not planned to be used, please define a new profile for that, rather than using profile 1, 2, and 3…” I don’t need to define new profiles if I don’t want to use DHss||MLKEMss and I gave you 4 very good examples of why I don’t need to. It’s a perfectly legitimate line of reasoning.

Don’t try to impose unnecessary constraints on work in this TG. And please consider solutions that are more efficient than what you propose.

Regards,

Dan.

“the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane.” – Marcus Aurelius

On 9/15/26, 8:42 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:

Hi Dan,

Thanks for your response.

I don't have any problem adopting the current PTK derivation equation using profiles 1, 2, and 3 for PQC PAKE and PQC no authentication mode,

you can implement a similar design as proposed in 26/1202r4 and 26/1203r4. We don't need any constraints on a special AKM.

As I said in the reflector, the current draft still allows the use of other PQC profiles if new PQC parameters are employed.

Hi Jouni,

I'm not sure it is a good time to jump into the discussion of other PQC schemes suddenly in this email thread.

If such changes are relevant to other PQC schemes, perhaps you can leave them as they are until we complete the design of the other PQC scheme.

杨志杰10343608

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: Harkins,Dan <daniel.harkins@xxxxxxx>

To: 杨志杰10343608;STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>;

Date: 2026年09月16日 12:27

Subject: Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments

Hi Jay,

I strongly disagree. The text belongs where the protocol generating the PMK, and calling to derive a PTK, resides. Not in 12.17.5. Each PQC exchange that generates a PMK will explain all the stuff it needs to call the generic (not profile or exchange specific) PTK derivation function.

If you would like to see how a new PQC key exchange can use 1, 2, or 3 but not have the “DHss || MLKEMss” construct please see 11-26/0089r7, specifically how it modifies the table in 9.4.2.239 (Security Profile element) and how it constructs the components for PTK derivation at the end of 12.17.X.5. That is using the XXXKey/MLKEMlist terminology but since that is changing I will be updating the submission to use the new, correct, IKM/EPHKey terminology. But that’s how it works. In fact, you can see how it works in not only the PAKE but also my signature exchange (11-26/0546r6), the no-sig authentication exchange (11-26/0547r3), or my PQC OWE exchange (11-26/0545r3). They all do the same sort of thing and do not require the “DHss || MLKEMss” construct that 802.1X does.

Regards,

Dan.

“the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane.” – Marcus Aurelius

On 9/15/26, 5:15 PM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote:

Hi Jouni,

Thank you for your efforts on this.

As we discussed in the F2F just now, the usage of PQC parameters is not constrained by any AKM according to the design in 11bt draft 1.0.

That is, for any PQC scheme, e.g., the DHss || MLKEMss will be included when PTK is derived from PMK using PQC profile 1, 2, and 3, while such ideas are lost if you add any AKM constraint, e.g., add " if the AKM is XXX, EPHss is MLKEMss for PQC profile 0 and DHss || MLKEMss for PQC profiles 1, 2, and 3" .

And thus, I still think these parts should be in 12.17.5 as it is the general description without any AKM limitation.

In fact, if the DHss||MLKEMss is not planned to be used, please define a new profile for that, rather than using profile 1, 2, and 3, it is still allowed according to the design in the current draft.

In all, the usage of PQC parameters should rely on the selected PQC profile, not AKM.

杨志杰10343608

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: JouniMalinen <jkmalinen@xxxxxxxxx>

To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>;

Date: 2026年09月16日 10:52

Subject: Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments

https://mentor.ieee.org/802.11/dcn/26/11-26-1870-02-00bt-transcript-and-ptk-derivation-comments-on-p802-11bt-d1-0.docx
is now on the server. It proposes resolutions to these CIDs:
115, 122, 123, 125, 130, 131, 132, 173, 214, 245, 254, 255, 256, 281,
282, 283, 284, 286, 288, 289, 331, 344, 345, 346, 365, 366, 431, 467,
529, 532, 549, 589, 664, 665, 666, 667, 709, 710, 742

Please note that CID 173 is not currently assigned to me, but it
belongs to topics covered in these groups and needs to be addressed
together with the other CIDs listed here and it should be assigned to
me. IMHO, its current group (PDT-FILSFastSetup) is incorrect.

1870r2 has following changes from r1 that I started presenting today:
- Remove exclusion of Vendor Specific elements from transcript based
on discussion during the Tue PM1 slot and additional offline comments
pointing out that we already include Vendor Specific elements in the
MIC element in the 802.1X Authentication frames.
- Add proposed resolution for CID 431
- More complete resolution for CID 664
- Move comments on restructuring of items that are not strictly
speaking on transcript or PTK derivation to another section. The plan
is to not address these comments in this document.
- Added more details on proposed comment resolutions.
- Added a list of CIDs that the document proposed resolutions for.

This completes the work I'm planning on doing this document and as
such, I think resolutions for the CIDs listed above would be ready for
a motion once we complete presentation of updated revision and address
comments, if any, coming up offline before the presentation or during
that presentation.

- Jouni

On Tue, Sep 15, 2026 at 1:44 PM Jouni Malinen <jkmalinen@xxxxxxxxx> wrote:
>
> 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

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