Re: [STDS-802-11-TGBN] 11-25/2015 - lb291-mac-cr-for-cid-4808-in-37.16.5

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

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