| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Reject as out of scope. --
Tao Chun Lee | Tech Manager, Standards | Communication System Design, MediaTek Inc. Email: TaoChun.Lee@xxxxxxxxxxxx | Phone: +886 3 560 0868 | Website: www.mediatek.com -----Original Message----- External email : Please do not click links or open attachments until you have verified the sender or the content. Hello, I'd say CID 225 is a candidate for rejection. It is saying that a key exchange that does not exist in the standard "may" have some issue if and when it does. Draft 1.0 doesn't contain any mechanism to bind "a successfully established
PQC PASN key" because there is no such thing as a successfully established PQC PASN key! It makes no sense to add some binding mechanism to a draft that does not contain the thing it needs to bind. Maybe when an exchange that generates a successfully established PQC PASN key is adopted into the draft such a mechanism can be added at that time if the group thinks this really is a problem. For now? Reject. 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/14/26, 3:15 PM, "Jouni Malinen" <jkmalinen@xxxxxxxxx <mailto: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://urldefense.com/v3/__https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1__;!!NpxR!gc8EkC1jo6QsWJNstIaT3kg86akHjogz6potmDBnstERSRRBX6ReF5mcOS7UsO7vuNWFiRe_El8o43eZ8C8$ <https://urldefense.com/v3/__https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1__;!!NpxR!gc8EkC1jo6QsWJNstIaT3kg86akHjogz6potmDBnstERSRRBX6ReF5mcOS7UsO7vuNWFiRe_El8o43eZ8C8$> ________________________________________________________________________ To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://urldefense.com/v3/__https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1__;!!CTRNKA9wMg0ARbw!g2FHjP02Hn2CR8XbTicBw2hIO-O3CdV_blQ_sVgkJX47_LQiubLBwCrxOUe-v3F84nSC3OjbzZPNQ1iZLH24oKAt1VCGCK9wWlXs$ ************* MEDIATEK Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! 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 |