| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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-------------------------------à|
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 |