(#5969, #6887)The SMD -ME and the AP MLDs within an SMD need to have a secure channelbetween them that can be used to exchange cryptographic keys and associated security context without exposure to intermediate parties.The cryptographic strength of th is secure channel needs to be greater than or equal to the cryptographic strength of the channels for which the keys are used.
Regarding the above proposed text, I understand its revised from the following baseline text:
The R0KH and the R1KH need to have a secure channel between them that can be used to exchange cryptographic keys without exposure to any intermediate parties. The cryptographic strength of the secure channel between the R0KH and R1KH needs to be greater than or equal to the cryptographic strength of the channels for which the keys are used.
The question is still here to the group, how to compare the cryptographic strength among different transmission medium? It's wrong to use absolute cryptographic strength for the comparision of different transmission media, seems it's OK to use some word like effective Crypotographic strength if we can reach some consensus on a general equation "Effective Crypto Strength=Algorithmic Strength−Media Security Loss", then we need to define the factors of Media Security Loss. My 2 cents.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: BinitaGupta <bingupta.ieee@xxxxxxxxx>
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;
Good spot, thanks. Either I missed those or they got introduced via some other resolution in the last round. Either way, if you could handle those similarly it would be great.
Best
Thomas
On May 7, 2026 at 15:41:02, Binita Gupta (binitag ) <binitag @cisco.com> wrote:
Hi Thomas,
Thanks for your detailed response and discussion.
I see your point about not introducing new noun terms for these PTKs to avoid the confusion of whether other PTK references apply to these PTKs .
In D1.4, I do see these two references for Per-SMD PTK and Per-AP MLD PTK .
I am good to change these as - ‘...a PTK at the SMD level is derived…and that PTK is then used...’ and ‘a PTK at the AP MLD level is derived…and that PTK is then used…’
And use similar naming where needed to clarify the PTK level/scope.
Many thanks for your careful responses, in general your proposed updates sound good.
On the PTK naming, while I tend to think the scope/level is clear from the context of the sentence, if you feel a more explicit description is needed, my preference would be to say something like "PTK at the SMD level" or similar.
Mainly, I prefer to avoid reintroducing the noun phrases "per-SMD PTK " and "per AP MLD PTK " since there seemed to be confusion (based on other CIDs ) as to whether all the other references to "PTK " in baseline (e.g. in PTK derivation formulas) apply to those noun phrases.
I believe the only instances of those strings in D1.4 are in the names of the "modes", e.g. "per AP MLD PTK mode".
It mostly looks fine but I have a couple of small-ish comments:
a Per-SMD
P
TK is
derived
as described in
37.15.4.1
We removed existing instances of "Per-SMD PTK " and "Per AP MLD PTK " to address other CIDs in 426r11, and instead just refer to a "PTK ". So I think we should not reintroduce these terms here. I think the sentences you added would still be clear if those phrases are removed. (multiple instances)
BG>> I see. How about using SMD -level PTK instead? I think it would be good to clarify that the PTK is at the SMD level. We use SMD -level terms in many places in D1.4.
The
exchange
d
keying material
includes the
PMKSA
and PTKSA
established between the SMD -ME and
a
non-AP MLD .
Could we slightly soften this to say something like "The exchanged keying material might include components of the PMKSA and PTKSA ...."? Since, depending on the case, not all the keys are transferred
BG>> Sure, I am good with softening this.
In the case of a single MAC SAP for the SMD , the 802.1X Authenticator in the SMD -ME controls(#12308) the 802.1X Controlled Port for the non-AP MLD
(#41
6
3)and there is no 802.1X Authenticator component in the AP MLD
.(#4723)
I note Duncan added the following text in 380r3 (in 4.9.7), which seems to be applicable to both architectures: The SME of an AP MLD that is part of an SMD contains an SMD -ME that is shared among AP MLDs of the SMD and that is responsible for coordinating the SMEs of those AP MLDs . The SMD -ME is responsible for coordinating with each of the SMEs to ensure that a single RSNA key management entity and IEEE 802.1X Authenticator or Supplicant are shared among the MACs and that a single IEEE 802.1X entity is controlled.
This says there is a single "802.1X entity" in an SMD -ME, irrespective of the architecture - which for network-side means a single 802.1X Authenticator per SMD -ME. In Per AP MLD MAC-SAP case, where there are many 802.1X Controlled Ports in the SMD (one per AP MLD ), that would mean the single 802.1X Authenticator contains many PAEs (Port Access Entities) that are logically distributed. In the Per SMD MAC-SAP case, there is just a single Controlled port so a single "centralized" PAE (in an undefined location).
However, one of the roles of the 802.1X Authenticator in the SME is key management (e.g. set/delete keys, manage PNs , etc). At least for group keys, that is all done at the link (per AP) level. And even for pairwise keys, although the architecture does not preclude an implementation centralizing crypto and key management, logically this is at the AP MLD level.
So while we might say there is no PAE component of the 802.1X Authenticator in (the SME of) an AP MLD , I'm not sure we can say there are no components of the 802.1X Authenticator in the AP MLD at all.
BG>> Thanks for detailed explanation, and this makes sense. I am good to say "...and there is no PAE component of the 802.1X Authenticator in an AP MLD ."