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

Re: [STDS-802-11-TGBT] 11-26/1163r2

 

  Hi Thomas,

 

  Can you provide some data to support the contention that “failed PMK caching attempts are quite common in the field”? And by “quite common” what do you mean? Is 10% “quite common”? Is 25% “quite common”?

 

  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 6/19/26, 2:34 PM, "Thomas Derham" <thomas.derham@xxxxxxxxxxxx> wrote:

Hi Dan, Jay, all

 

If the group insists on doing 802.1X and PMK caching simultaneously then ...

 

It seems that failed PMK caching attempts are quite common in the field, and the subsequent fallback to full authentication exchange increases connection time. For example:

  • Some STAs assume/hope a network might support ESS-wide PMK caching (aka OKC) so try it first. If the AP doesn't have the PMK, this fails. While the standard provides methods by which a PMK caching domain (across multiple AP (MLDs)) can be advertised - e.g. FILS Cache ID - they are not widely supported.
  • Even for same-AP (MLD) PMK caching, if the AP deletes the cached PMK for whatever reason, the STA's subsequent attempt to use it prior to its expiry will fail

 

I don't have a strong opinion about how it is done technically (and how to optimize the trade-off with "wasted" compute), but I think a procedure that gracefully continues with full auth if PMK caching fails would be beneficial overall.

 

Thanks

Thomas

 

 

 

On Jun 18, 2026 at 16:32:04, "Harkins, Dan" <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

 

  Jay,

 

  It’s not that I’m not familiar with 0.3, it’s that I do not think it is a high quality document and it needs a considerable amount of work before we can get to 1.0. Also, we are not bound by anything that’s in 0.3. It is not etched in stone. We can change it as we see fit.

 

  So what you’re saying is that if the originator is offering to do PMKSA caching, in its simultaneous EAPOL start request it will include an ML-KEM encaps key and optionally a Diffie-Hellman parameter element. And if the Authenticator does not recognize any PMKID it does not include an ML-KEM ciphertext nor a Diffie-Hellman parameter element in the response. Which means the STA is doing quite a bit of work for nothing. That is extremely regrettable. And that is because are combining two fundamentally different exchanges into one, which is not a wise thing to do. Notice how we’re now in this predicament of requiring unfortunate and “special design” for parsers that unnecessarily complicates things because of this architectural design choice.

 

  If that’s the case then let’s fix it. We are under no obligation to follow a poor architectural design at this point. We are greenfield.

 

  802.1X should do 802.1X. PMK caching should do PMK caching. The argument to combine them was that the STA could avoid an extra message in the event that the Authenticator does not have a hit in the PMK cache. But when that does happen, it is at a cost of doing extra work that gets thrown away so what’s the benefit? There is none. “Let’s potentially save a message by doing a whole bunch of extra work that gets thrown away” is not a compelling argument.

 

  If the group insists on doing 802.1X and PMK caching simultaneously then we should just always include a ciphertext, and optionally a Diffie-Hellman public key, in the frame with transaction sequence number set to 2. Then don’t do (an) additional exchange(s) after the EAP success frame. EAP success is the end. Just like it is in the *real* baseline, IEEE Std 802.11-2024. No need to send additional Authentication frames. We will have an MLKEMss and optionally a DHss and we can use them with the PMK generated by EAPOL. In the event that EAPOL fails then each side has stuff to throw away but this is not a DoS attack because it requires the STA to get so heavily involved in the exchange that a distributed attack to overwhelm the Authentiicator is not going to happen. 

 

  Let’s fix this. Which way is better? Separating the two or always doing an ML-KEM.encaps (+DH) in the second message? Or do you prefer an architecture that compels a complicated “special design” in parsers and forces STAs to do extraneous work that it just throws away?

 

  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 6/18/26, 3:32 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:

Hi Dan,

 

In 11bt draft0.3,

Authentication transaction sequence number 1 not always having an encapsulation key and potentially a Diffie-Hellman key. The one with Authentication transaction sequence number 2 not always having a ciphertext and potentially a Diffie-Hellman key". It's based on the following highlight condition. If you remove such condition, then you will get the confused conclusion, "Why are there 2 Diffie-Hellmans and 2 ML-KEM exchanges being done? Why isn’t 1 enough? We just need a single MLKEMss and single DHss plus a PMK to derive the PTK"

 

Also, the following texts in your contribution assume that RSNE is put ahead of PQC Encapsulation Key field. Then the mistake starts...

cid125027*image001.png@01DCFF3F.FD1F4620

 

PS: I do feel you're not very familiar with current baseline text(11bt draft0.3), that's why we debate back and forth many rounds in the reflector, I really sorry to say that!  

 

Please correct me If I make any mistake or misunderstand your points via our conversation.

 

 

 

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

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

To: 杨志杰10343608;

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

Date: 2026年06月19日 00:42

Subject: Re: [STDS-802-11-TGBT] 11-26/1163r2

 

  Jay,

 

On 6/18/26, 5:56 AM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote:

 

Transaction sequence number 1 has an encapsulation key, 2 has a ciphertext, and the transaction sequence number after the frame carrying the EAP success (which both sides will know) will have an encapsulation key, and the one after that (“the last authentication frame”) has a ciphertext.

 

--><Jay> Thanks for the elaborated explanation. I understand now, but it doesn't work at all in PMKSA caching case. As RSNE is put after all the fields. When the receiver received the 1X authentication frame, it can't determine whether such frame including encapsulation key field or not until decoding RSNE (including PMK ID list). Then...the bug happened! And you have to define new signaling to fix it.

Sure, the receiver can infer the encapsulation key field and ciphertext field present or not based on the previously content and content combination(like Transaction sequence number here ) via the elaborated signaling design. But there is nothing wrong if we can provide the content present signaling as the baseline has, which allows the transmitter indicates these fields present or not explicitly to the receiver . For what, make the system more robust.

 

Not sure what the bug is. The PMK caching frame with Authentication transaction sequence number 1 has an encapsulation key and potentially a Diffie-Hellman key. The one with Authentication transaction sequence number 2 has a ciphertext and potentially a Diffie-Hellman key. The size of all of them are determined by security profile number. Now you can get to the RSNE and decide whether the PMKSA being cached exists and, if you do the “downgrade” work you proposed, whether the security profile number being negotiated is consistent with the one in the PMKSA. If so, continue; if not, fail.

 

There’s nothing elaborate about this.

 

If we put such field after a special element, a lot of issues can be fixed,  Per Jouni pointed out in another mail thread, just need to add some special design  in the parsing (e.g., knowing that there are suddenly fields after a specific element). 

 

That’s an interesting take on Jouni’s email. I didn’t read it as him saying we just need to add some “special design”. I read his email as saying he doesn’t want to do what you are proposing because it makes things much more complicated. The way I read it is he prefers my approach which makes parsing simpler.

 

And you say “a lot of issues can be fixed”, yet you do not list any of them.

 

Also, I didn’t miss the irony where you are suggesting adding a requirement for a “special design” to parsers right after criticizing a different, simpler, approach as being elaborate.

 

  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

 

 

 

杨志杰10343608

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

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

To: 杨志杰10343608;     

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

Date: 2026年06月18日 07:08     

Subject: Re: [STDS-802-11-TGBT] 11-26/1163r2     

 

  Hi Jay,

 

  We don’t need to predict how many messages will be sent. Transaction sequence number 1 has an encapsulation key, 2 has a ciphertext, and the transaction sequence number after the frame carrying the EAP success (which both sides will know)  will have an encapsulation key, and the one after that (“the last authentication frame”) has a ciphertext.

 

  While we’re on that topic. Why are there 2 Diffie-Hellmans and 2 ML-KEM exchanges being done? Why isn’t 1 enough? We just need a single MLKEMss and single DHss plus a PMK to derive the PTK.

 

  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 6/17/26, 3:53 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx>  wrote:

 

Hi Dan,

 

Thanks for the response.

 

 

"You will know whether an encapsulation key or ciphertext is present by the transaction sequence number "

<Jay> Please tell me the exactly transaction sequence number of 802.1X authenication frame including encapsulation key or ciphertext? The problem  lies in your can't predict how many authenticaiton frames exchanged during 802.1X procedure. And that's why we need the Content Presence field here.

 

杨志杰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年06月18日  04:00  

Subject: Re: [STDS-802-11-TGBT] 11-26/1163r2  

 

  Jay,

 

  The Content Presence field is entirely unnecessary. You will know whether a public key is present and its size by the security profile number. You will know whether an encapsulation key or ciphertext is present  by the transaction sequence  number and you’ll know the size by the security profile number. These are lockstep protocols where one side sends an encapsulation key in one frame and the other sends a ciphertext in the other. If I’m sending a frame that requires  an encapsulation key per  the specification of the protocol then why do I need to additionally tell you that my message has a field that the standard dictates to be present is actually present? It’s pointless!

 

  So what you’re advocating for is 4 octet element that conveys a single octet of information: the security profile number. Why not just have that single octet of information which we will know is there due to the  Authentication algorithm?

 

  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 6/17/26, 12:44 PM, "Jay Yang" <yang.zhijie@xxxxxxxxxx> wrote:

 

Hi Dan,

 

Thank you for your efforts on this.

 

I would like to understand the exact parsing issue if we design the PQC parameters as follows: Place the KEM Encapsulation key field and KEM   Ciphertext field immediately after the PQC Parameter element.

 

 

 

                  |<-------------------------------PQC Parameter element-------------------------------à|

Element ID

Length

Element ID   Extension

Security Profile   Number

Content Presence   field

Public Key   Parameter

KEM   Encapsulation Key

KEM Ciphertext

Octets: 1                         1                        1                1                          1                        variable               variable                variable

 

 

The receiver parses it as follows:

 

1.      If the PQC element is not present, the KEM Encapsulation key and KEM ciphertext are also not present. The receiver does not need to decode the additional two fields  if it cannot find the  PQC Parameter element based on the element PQC Parameter element's TLV information.

2.      If  the PQC Parameter element  is present, based on the indication in  the Content Presence field. For example, if  the Content Presence   field indicates that the ML-KEM public key is included in the KEM Encapsulation   key field , the receiver will continue to decode the KEM Encapsulation key field after decoding  the PQC Parameter element.

3.      If  the PQC Parameter element  is present, based on the indication in  the Content Presence field. For example, if  the Content Presence field indicates that  the KEM Encapsulation key or KEM ciphertext are not present (e.g., Content Presence field equals 0 (No parameter present) ), the receiver will not decode  the KEM Encapsulation key or   KEM ciphertext   after finishing the decoding of  the PQC Parameter element. Instead,   it will continue to decode other elements based on the TLV information.

 

If we proceed in this direction, we could address a number of comments (compatibility issues, frame-by-frame design issues, etc.) we received   during the call.

 

Welcome to more insights from you and the group.

 

 

 

杨志杰10343608

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

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

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

Date: 2026年06月18日   02:25  

Subject: [STDS-802-11-TGBT] 11-26/1163r2  

 

  Po-kai,

 

  In the teleconference today you said that the changes I’m proposing in 11-26/1163r2 also require changes to the PQC Security Profile Number values but you didn’t say what they are. Can you explain what changes   my document is missing?  Thanks.

 

  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

 

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

 

 

 

 

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