Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments
Hi Jouni,
Citation:
In other words, in attack cases, there might be multiple instances of an Authentication MMPDU with the same authentication transaction sequence number. The D1.0 text does not define what should be done in such cases and if this is to be interpreted as the last (or first) Authentication frame with a specific transaction sequence number, it would not protect against certain attacks.
[Po-Kai]: Let's use your example above about multiple multiple instances of an Authentication MMPDU with the same authentication transaction sequence number. I can not understand why you claim that texts in D1.0 does not catch this case, and I also do not understand why your new texts clarify this case.
Consider the following examples from the perspective of the client. Say client see 3 instances of Authentication frame 4. Does the client include all of them in the transcript based on your new texts? However, you just mention that if the second instance and third instance are actually retry, then client will not include them.
Send Authentication frame 1
Receive Authentication frame 2
Send Authentication frame 3
Receive Authentication frame 4 first instance
Receive Authentication frame 4 second instance
Receive Authentication frame 4 third instance
For your claim that D1.0 will not catch the attack, I do not understand the claim. My personal understanding is that if the client sees the first instance of authentication 4, then the client will take that and processed. If client sees further instance of authentication frame 4, then the client is supposed to drop it since it already sees transaction sequence number 4.
If the first instance is from the attacker with different content from the AP, then the transcript construction on client and real AP will be different, so MIC will catch that. No?
Can you provide the actual sequence to explain why D1.0 can not address your attack but the new text with all the note addition can?
Best,
Po-Kai
-----Original Message-----
From: Jouni Malinen <jkmalinen@xxxxxxxxx>
Sent: Wednesday, September 16, 2026 9:15 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments
Please also note that one of the purposes of the transcript is to protect against active attacks where the attacker might postpone delivery, send modified versions, omit some frames, or reorder frames.
In other words, in attack cases, there might be multiple instances of an Authentication MMPDU with the same authentication transaction sequence number. The D1.0 text does not define what should be done in such cases and if this is to be interpreted as the last (or first) Authentication frame with a specific transaction sequence number, it would not protect against certain attacks.
In the case of a normal authentication without any active attacks in progress, I'd expect the exact same transcript hash to be generated for the PQC options defined in D1.0 (i.e., IEEE 802.1X) regardless of which of these two alternatives were used.
For some attack cases, behavior would be different. It would be fine to detect those based on two different ways of calculating a different transcript hash, but it would not be fine if both ends use the D1.0 design and end up deriving the same transcript hash value due to the attacker having injected additional frames to hide differences in what the real participants in the authentication thought were exchanged.
- Jouni
On Wed, Sep 16, 2026 at 5:55 AM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:
>
> Hi Jouni,
>
> Thanks for the update. I will read the new revision. I guess my point is that the current text in D1.0 directly exclude all these cases without a note.
>
> Now, we generalize the texts, but we have to introduce a bunch of note whenever someone like me brings the questions. This seems to prove that the normative language itself is not strong enough, and are we even sure that we cover all the cases to avoid interop issues?
>
> Asking the questions in another way, if I still implement the transcript construction based on transaction sequence number because I think that is equivalent to the order of exchange, is that accurate or that is not even accurate?
>
> Best,
> Po-Kai
>
> -----Original Message-----
> From: Jouni Malinen <jkmalinen@xxxxxxxxx>
> Sent: Wednesday, September 16, 2026 8:51 AM
> To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
> Cc: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-11-TGBT] Transcript and PTK derivation comments
>
> PoW is handled differently in r3, so that is not applicable for this
> anymore,
>
> Rejection of an authentication results in a new authentication being started so the Authentication frames up to and including such rejection are not part of the new exchange. I would be open to adding a NOTE to point this out, if that would help.
>
> Retries of the MPDUs are covered in a NOTE in r3, i.e., they do not get added into the transcript.
>
> Transcript is supposed to be a collections of messages exchanged between the parties in the exact order those messages were exchanged.
> Hardcoding this to be in the order of the Authentication transaction sequence number feels wrong in that context.
>
> - Jouni
>
> On Wed, Sep 16, 2026 at 5:44 AM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:
> >
> > Hi Jouni,
> >
> > I have a comment about the proposed approach to strip away the current explicit definition of transcript based on the transaction sequence number and replace that with the following.
> >
> > "The transcript includes Authentication MMPDUs up to and including the one that results in derivation of the PTK."
> >
> > Form my side, this seems to introduce further ambiguity. If I understand it correctly, the motivation for the change is to handle the PoW case. However, I am not sure that is needed and whether we are introducing a technical change.
> >
> > Consider the following example. My understanding is that the first two exchange are not part of the transcript computation based on D1.0 Also, the Authentication frame 1 with PoW1 solution will have the challenge anyway, which already bounds with the previous exchange. The new text seems to suggest that we have to additionally include the first two message as part of the transcript, which I can not understand why we have to enforce that.
> >
> > Authentication 1 => Not part of the transcript based on D1.0. part of the transcript based on the new texts???
> > Authentication 2 (PoW1) => Not part of the transcript based on D1.0. part of the transcript based on the new texts???
> > -------------------------------------
> > Authentication 1 (PoW1 solution) => part of transcript
> > Authentication
> > 2 => part of transcript ...
> > Authentication n => part of transcript
> >
> > The texts also introduces ambiguity on the following case, which can be expanded to all sorts of rejection reason. Do we have to include all the exchange that AP sends back with authentication rejection? If so, how far back we have to remember this? If a client gets rejection and leave the office and comes back the next day to connect, do we have to remember the rejection in the previous day?
> >
> > Authentication 1 => Not part of the transcript based on D1.0. part of the transcript based on the new texts???
> > Authentication 2 (Rejection security profile not supported) => Not part of the transcript based on D1.0. part of the transcript based on the new texts???
> > Authentication 1 => part of transcript Authentication 2 => part of
> > transcript ...
> > Authentication n => part of transcript
> >
> > Another ambiguity around this is on the possibility of retry/resend. Texts on D1.0 is very clear on all these cases, but the new texts now bring questions.
> >
> > Authentication 1 => part of transcript Authentication 2 => part of
> > transcript for AP but not non-AP because non-AP does not receive
> > Authentication 2 (retry/resend) => part of transcript for non-AP
> > because non-AP receives, but not part of the transcript again for AP ...
> > Authentication n => part of transcript
> >
> > Best,
> > Po-Kai
> >
> >
> > -----Original Message-----
> > From: Jouni Malinen <jkmalinen@xxxxxxxxx>
> > Sent: Tuesday, September 15, 2026 7:52 PM
> > To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx
> > 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-
> > an d-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-transcr
> > > > ip
> > > > t- 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