[STDS-802-11-TGBT] Transcript and PTK derivation comments
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