| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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>
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:
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 |