| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 (杨志杰)
OriginalFrom: ZhaoXuwen <zhaoxuwen123@xxxxxxxxxxx>To: Thomas Derham <thomas.derham@xxxxxxxxxxxx>;Cc: M Montemurro <montemurro.michael@xxxxxxxxx>;STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;Duncan Ho <dho@xxxxxxxxxxxxxxxx>;binitag@xxxxxxxxx <binitag@xxxxxxxxx>;杨志杰10343608;huangguogang1@xxxxxxxxxx <huangguogang1@xxxxxxxxxx>;周培 <zhoupei36@xxxxxxxxx>;Date: 2025年11月07日 16:18Subject: 回复: [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
发件人: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
发送时间: 2025年11月7日 15:22
收件人: Zhao Xuwen <zhaoxuwen123@xxxxxxxxxxx>
抄送: M Montemurro <montemurro.michael@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Duncan Ho <dho@xxxxxxxxxxxxxxxx>; binitag@xxxxxxxxx; yang.zhijie@xxxxxxxxxx; huangguogang1@xxxxxxxxxx; 周培 <zhoupei36@xxxxxxxxx>
主题: Re: [STDS-802-11-TGBN] 11-25/2015 - lb291-mac-cr-for-cid-4808-in-37.16.5 (roaming security issue)
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.
Thanks
Thomas
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.
On Fri, Nov 7, 2025 at 11:40 AM Zhao Xuwen <zhaoxuwen123@xxxxxxxxxxx> wrote:
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
发件人: M Montemurro <montemurro.michael@xxxxxxxxx>
发送时间: 2025年11月7日 12:20
收件人: Zhao Xuwen <zhaoxuwen123@xxxxxxxxxxx>
抄送: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Duncan Ho <dho@xxxxxxxxxxxxxxxx>; binitag@xxxxxxxxx; yang.zhijie@xxxxxxxxxx; huangguogang1@xxxxxxxxxx; 周培 <zhoupei36@xxxxxxxxx>
主题: Re: [STDS-802-11-TGBN] 11-25/2015 - lb291-mac-cr-for-cid-4808-in-37.16.5 (roaming security issue)
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.
Thanks,
Mike
On Wed, Nov 5, 2025 at 10:17 PM Zhao Xuwen <zhaoxuwen123@xxxxxxxxxxx> wrote:
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
Thanks,
Xuwen Zhao
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