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".
Thanks Thomas for your feedback.
Please see some responses below, and mostly good with your suggestions.
Thanks Binita for the hard work on this.
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."
I will revise accordingly.
Thanks,
Binita
Thanks
Thomas
One typo correction below:
Hi Roaming TTT members,
I have revised CRD
25/2339r1 based on changes already made in D1.4 from Thomas's CRD
26/426r11.
Suggested changes in r1 should be straightforward. Please review and let me know if you have any feedback.
Thanks,
Binita
Hi Roaming TTT members,
I have uploaded CRD
11-25/2339 which resolves 15 CIDs related to roaming on following topics:
- Per-SMD PTK
- SMD-level PMK
- SMD-level PMKSA
- PTKSA for two PTK modes
- Group Key Data in UHR Link Reconfiguration Response
- Status codes for roaming
Could you please review the proposed resolutions and provide any comments/feedback you may have.
Thanks,
Binita
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
