Hi Thomas, Duncan, Binita and Jay
Thanks for your comments.
I would like to use the following as a unified response to all of your comments:
-
I do not intend to introduce a mandatory key retrieval mechanism that would exclude push or pull models for the target AP MLD to obtain the key. What I want is simply to give the target AP MLD the
possibility of having an alternative key retrieval method. Just as in the development of the 802.11r amendment, a similar issue arose with PMK-R1 — the protocol between the R0KH and R1KH was left to implementation, but a PMKR1Name was still defined so that
the R1KH could request the PMK-R1 from the R0KH:
13.5.3 Over-the-DS FT protocol in an RSN
The R1KH of the target (#11be)FTR uses the value of PMKR0Name and other information from the frame to calculate PMKR1Name. If
the target FTR does not have
the key identified by PMKR1Name,
it may retrieve that key from the R0KH identified by the FTO. See 13.2 (Key holders). Upon receiving a new PMK-R1 for a FTO, the target FTR shall delete the prior PMK-R1 security association and PTKSAs
derived from the prior PMK-R1.
-
Therefore, I think it would be reasonable to add a NOTE indicating this possibility:
NOTE — The PTK for an AP MLD can be identified and retrieved by the target AP MLD and the SMD-ME using the PTK ID.
-
I apologize for not carefully distinguishing between the PTKName defined in the existing baseline. To differentiate it, I am temporarily using the term PTK ID to denote the identifier of the PTK.
This identifier can be computed during the initial association and authentication process. Whether the specific PTK ID calculation formula is needed and what it will be can be further discussed.
If you have any further comments on the above draft responses, please let me know.
Thanks,
Xuwen Zhao
TCL
发件人: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
发送时间: 2025年11月8日
10:47
收件人: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN]
回复: [STDS-802-11-TGBN] 11-25/2015 - lb291-mac-cr-for-cid-4808-in-37.16.5 (roaming security issue)
Thanks for the discussion.
I agree with Duncan's suggestion to add some language about assumptions on the transport for key distribution between SMD-ME and AP MLDs.
As for (what I think is) the original point of how the key to be shared (SMD_KDK or PTK) is to be *identified*, first it seems we need to decide if the SMD-ME ensures there is only a single active SMD_KDK or PTK (depending
on PTK mode) per Non-AP MLD in the SMD at a given time. If that is ensured, then it seems sufficient to just say the SMD_KDK or PTK is identified by the Supplicant's MAC address. If it can't be ensured (possibly due to some edge cases related to how reassoc/diassoc/deauth
with SMD-ME is handled), then it might need to be identified by something else. Either way, I think this identification can be done purely on network side so not clear it needs to be indicated over the air.
Hi Xuwen,
Thanks for your contribution. I tend to agree with Thomas and Binita. I took the FT text that Binita mentioned and modified it as follows
for discussion here:
“The SMD-ME and the AP MLDs that are managed by the SMD-ME 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 SMD-ME and the AP MLDs needs to be greater than or equal to the cryptographic strength of the channels for which the keys are used.
The protocol for distribution of such keying material is outside the scope of this standard.”
The idea is there are different deployments in the market and we do not want the 802.11 spec to limit/force any implementation. This
has been the principle from the beginning of seamless roaming spec development. That’s why you don’t see the backhaul transport mentioned in D1.0. However, the understanding
has been we need to add some text like the above to clarify the security requirements of the backhaul.
Thanks,
Duncan
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Thanks for the contribution.
I agree with Thomas's comment that we need to allow both push or pull models for the target AP MLD to get
the PTK (in the Per-SMD PTK mode) or to get the SMD-KDK in the Per-AP PTK mode. We should not be mandating one model over the other, and different implementations can choose what works best.
We do need to add text covering that the distribution of keys is done over a secure transport, similar to
the related text we have for FT. But other than covering that keys are distributed over secure transport between SMD-ME/AP MLDs, I don't see the need to define a new PTK Name for SMD roaming.
Hi Xuwen,
Thanks for your contribution.
I have some hard time to understand why the target AP can't obtain the "NEW PTK" from the SMD-ME/current AP via push or pull mode mentioned by Thomas bellow.
What's the purpose to involve PTKName concept, please very be carefully saying the PTKName already in baseline. At this moment, I only see one sentence to say how to generated PTKName
in FT case in baseline. But not sure how it is used in FT protocol. It's preferred if there is some recap section on the usage of PTKName in the baseline in this CR. Also, I think you need to define the PTKName generation equation in
37.16.5.3/4 as well.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
Subject: 回复: [STDS-802-11-TGBN] 11-25/2015
- lb291-mac-cr-for-cid-4808-in-37.16.5 (roaming security issue)
Hi Thomas,
Thank you for your feedback.
According to the current Draft 1.1 text, only the following steps are clearly defined: the initial association between the non-AP MLD and the SMD-ME, the ST preparation request/response exchange
between the non-AP MLD and the current AP MLD, and part of the interaction between the current AP MLD and the target AP MLD. However, there is no explicit description of how the target AP MLD obtains the final PTK (in the per-SMD PTK mode) or how it obtains
the SMD-KDK to derive a new PTK (in the per-AP MLD PTK mode). This omission can easily cause confusion for readers.
Actually, the PTK and PMK ultimately used between the non-AP MLD and the target AP MLD are both derived from the initial association between the non-AP MLD and the SMD-ME, rather than from the
key shared between the non-AP MLD and the current AP MLD. The original draft text is as follows:
If the per-SMD PTK mode is used, a PTK is derived when the non-AP MLD performs initial association to the SMD-ME (see 37.16.3 (Initial association to the SMD-ME)). This key is derived from the PMK established
with the SMD-ME,
If the per-AP MLD PTK mode is used, a PTK and SMD_KDK are derived when the non-AP MLD performs initial association to the SMD-ME (see 37.16.3 (Initial association to the SMD-ME)). These keys are derived from
the PMK established with the SMD-ME,
For the per-SMD PTK mode, If you believe that transfering the PMK ID is not appropriate, I think passing the PTK Name to the target AP MLD (see 11-25/2016r1) and letting the target AP MLD request
the old PTK from the SMD-ME based on that PTK Name is a reasonable approach. The PTK Name is already generated in the baseline, and passing it does not pose any risk of sensitive information leakage.
For the per-AP MLD PTK mode, the same issue exists: the PTK ultimately used between the non-AP MLD and the target AP MLD is re-derived from the SMD-KDK established between the non-AP MLD and
the SMD-ME, which means the current AP MLD likely has no knowledge of either the SMD-KDK or the PTK. Therefore, allowing the target AP MLD to receive the PTK Name, request the SMD-KDK from the SMD-ME based on that PTK Name, and then derive a new PTK accordingly
is also logically consistent.
As for the concern about the term “querying” the PTK, I think we can discuss using a more appropriate wording — for example, “obtain” or “request”
Thanks,
Xuwen Zhao
TCL
I agree that, in principle, the non-AP MLD and SMD-ME could concurrently maintain (cache) multiple PMKs.
However I don't think there's any ambiguity as to which PMK needs to be used on roam with target AP MLD, since it is equal to the PMK that was used to derive
the PTK that is currently in use between Non-AP MLD and *current* AP MLD. It's possible a network implementation might need to maintain that information at each AP MLD as the Non-AP MLD roams around, but I don't see any need to signal the PMKID explicitly
in the roam signaling. In that sense, I think I agree with Mike's thinking.
As for the PTK (which is only applicable in shared PTK case), clearly the PTK in use is also known by the current AP MLD and can be communicated to the target
AP MLD, so I don't see any ambiguity there either. As for the concept of "querying" the PTK, I don't think we should mandate any particular method of PTK distribution - the PTK might be proactively pushed or pulled/queried at any point before or when it is
needed. It seems obvious this distribution is needed and it's not obvious to me what else we need to signal or say about it.
PS I do think some text is needed about association procedures with the SMD-ME (including reassociation to the same SMD-ME, and disassociation), such as what
is expected to happen to association state at SMD-ME if the Non-AP MLD (re)associates to the same SMD-ME, possibly via another AP MLD. But that is not related to the security keys, and I think there are other CIDs in which it can be addressed.
Hi Mike,
thank you for your feedback.
In fact, I’ve prepared two options. The other CR document is
11-25/2016r1, which describes a solution where the Target AP MLD queries the old PTK from the SMD-ME based on the PTK Name and then derives the new PTK. I suggest you review 11-25/2016 as well
— its concept should be closer to your idea.
I don’t have a strong preference between the two options; what I’d like to do is to improve the process description
in the current Draft to make the overall procedure easier to understand.
Thanks,
Xuwen Zhao
TCL
Hello Zhao Xuwen,
I reviewed the changes and in my opinion, the information that you are looking to include would be in the scope of the PTK, not the PMK. The reason is because
in any of these transitions, the non-AP MLD is associated to the SMD-ME. The PTK is the key resulting from this association (a PMK, or PMK-R1 in the case of FT, can be cached for subsequent associations).
The PMK or PMKID do not need to be able to be transmitted from the SMD-ME to the target AP MLD.
It could be that we derive the following:
- For shared PTK, a PTKName
- For per-MLD PTK, a PTKName associated with the per-AP MLD PTK.
Dear SMD BSS transition(Seamless Roaming) TTT members,
I have uploaded the following CR doc that addresses roaming security issue.
Please review and share any feedback in this email thread.
11-25/2015
- lb291-mac-cr-for-cid-4808-in-37.16.5
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
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
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
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
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
|