Hi,
I also add my two cents here:
- As mentioned in previous e-mails, 802.11bh does not restrict any PASN/FTM with other ESSs. However, the mechanisms defined in 802.11bh
only help non-AP STA to be identified by APs in the same ESS.
- From specification point of view, as long as non-AP STA does PASN with two ESSs separately (say, ESS1 and ESS2), it can use the identifiers
(device ID/PASN ID, IRM) separately for each ESS.
- As an example: non-AP STA has PASN ID1 with ESS1 and PASN ID2 with ESS2. Now it can use PASN ID1 for ESS1, and PASN ID2 for ESS2. (note:
non-AP STA needs to do at least one PASN with each ESS to obtain the identifier(s))
Thanks!
BR,
Okan
From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, May 28, 2024 9:52 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Attention PASN/FTM experts: Discussion on the use/intent of PASN
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
|
Hi,
I think of this in a much simpler manner.
Firstly, if the STA wants the ‘network” to know where the STA is, then obviously the network must be able to identify the STA, i.e., know who it is. I find it difficult to think of a network
in this case that is not an ESS, hence, PASN ID (or indeed IRM) can be used. If the ‘network’ is not an ESS (i.e., it is simply a bunch of APs in the area), then the STA must simply use the same MAC Address (i.e., NOT RCM) to all the APs it PASNs with. In
this case, it does not use IRM or PASN ID and the APs know it is the same STA from the MAC Address.
Secondly, if the STA does not want the network to know where it is, but wants to know itself, then it will use RCM, but will not use PASN ID or IRM.
So, basically, PASN ID and IRM are only used with PASN when the APs/network are an ESS. TGbh does not need to consider any other case IMHO.
Graham
(I think) One thing though is that it is possible that the security can be extended beyond an ESS with FILS or SAE. Authentication frames (EAP-RP, or SAE in Wrapped Data IEs) can establish
the PMK for that AKM/ESS; that PMK is used in PTK derivation with PASN...
PASN Authentication security depends on a base AKM - and its corresponding PMK that was established earlier. If I understand correctly, that security is bound to the ESS and not to
the radio vicinity of the non-AP STA.
Having said, that one may be able to extend that security beyond the ESS if that is required, but that would require an extension (I would think)
+ Nehru
As far as I am aware the introduction of PASN in FTM exchange was to provide an ability to ensure that the measurement results are protected between unassociated
non-AP STA & AP since FTM measurements are often done (for location) with other APs besides the AP that the STA is associated with. Expanding PASN to share ‘device ID’ can potentially bring in new use cases where APs might need to be part of ESS, but like
Mark is highlighting ‘what is the scope of that correlation” and do we need to restrict it in the spec now and/or leave it for the applications to constrain?
Ali
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Try again with the reflector emails corrected.
Mark
Joe, all,
I’d like to clarify the “two main views”. At least in my opinion from the discussion, I think the views in question
are:
-
PASN _with a shared knowledge of the non-AP STA’s identity_ is used only within an ESS (for messaging between a non-AP STA and the set of APs that form a single ESS).
-
PASN _with a shared knowledge of the non-AP STA’s identity_ is used in an area and can be used with any AP that supports PASN (for messaging between a non-AP STA any AP that supports
PASN in “radio range” of the non-AP STA, independent of the AP’s ESS).
That is, I can well imagine PASN (as a generic concept) could be used independent of the APs’ ESS(s), but when some sort
of identification of the non-AP STA is used/needed/desired (to correlate FTM requests, or for other reasons – I’m not sure what all the uses cases might be) what is the scope of that correlation?
This is an important distinction, as it is the scope of the TGbh relevant aspect to all this to consider only the scope
of the non-AP STA _identification_ and therefore the ability to correlate the PASN interactions (per Joe’s “Background”) .
Mark
Dear PASN/FTM experts:
During today’s TGbh call a discussion was had regarding PASN and FTM use/use cases.
There were two main views provided by the attendees:
-
PASN is used only within an ESS (for messaging between a non-AP STA and the set of APs that form a single ESS).
-
PASN is used in an area and can be used with any AP that supports PASN (for messaging between a non-AP STA any AP that supports PASN in “radio range” of the non-AP STA, independent of the AP’s ESS).
I believe how this is “viewed” has implications for the use of PASN for FTM and location accuracy in general. This also has privacy impacts, as sharing an ID
outside of an ESS may cause the ID to be shared to unknow entities which may allow these entities to track the non-AP STA.
Hence, the group requested this email discussion and a better understanding of the PASN use cases.
Thank you, in advance, for your assistance to provide TGbh a better understanding of the use of and use cases for PASN and FTM.
Background:
TGbh is creating a PASN ID that can be used to identify a non-AP STA that is using random MAC addresses to improve its “privacy”, this PASN ID would allow the
non-AP STA to be identified by the AP/network. The PASN ID is not fixed and allows for some degree of privacy for the non-AP STA, while providing the AP/network with an “ID” for the non-AP STA (the AP/network is informed, in a non-specified manner, of the
PASN ID and can use that information to identify the non-AP STA).
Note: the use of the term network in this email basically includes all APs that can support PASN, this could mean; 1) all APs that are connected by some means,
that may or may not be in the same ESS, 2) all APs that are connected by being in the same ESS.
Regards,
Joseph
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBK list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBK&A=1
|