Re: [STDS-802-11-TGBH] discussion on PASN ID figure 12-0b

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

PASN is starting to dominate the device ID text.

Hence, thinking about it, and trying to be logical, I see 5 options:

Adopt the scheme that an AP always provides a PASN ID and a device ID (as per Li Yan’s proposal). Does involve big additions to text and requirement to always save a temporary PASN ID and a device ID, even if STA never uses PASN or uses IRM for PASN.
Just use a PASN ID when using PASN and accept that there is no correlation between device ID and PASN ID. i.e., when using PASN, the identification is linked only to PASN (and location). Simple addition to text. If STA never uses PASN or keeps PASN and location as a separate task (or uses IRM), then this is simple additional text.
Always use an opaque device ID for association, and authentication using PASN. Involves computations and forces opaque even if STA never uses PASN (or uses IRM).
Stick to device ID, but if used for PASN, accept that the device ID will be changed every authentication. Simple, but sort of destroys the idea that the device ID is a permanent thing. But again, if STA uses IRM….
Just don’t recommend device ID mechanism for PASN at all. IRM works seamlessly for PASN. If we consider that IRM should be used (or will in practice be used) for PASN then say in a Note “device ID is not recommended for use with PASN”, and/or just adopt #2 or #4 above.

Where do I stand?

I would personally go with #5 and then adopt #2 or #4, but I will not object to #1. If we go with #1, then we should also accept Okan’s new Annex so we don’t need the figures in the main device ID text.

Just my thoughts,

Thanks

Graham

From: Li Yan <li.yan16@xxxxxxxxxx>
Sent: Monday, June 17, 2024 9:09 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] discussion on PASN ID figure 12-0b

Hi Joe and Graham，

I'v uploaded the 789r5 to the mentor, where the figure 12-0b is modified as suggestion of Joe.

After the changes complete, i find the figure 12-0b is similar with figure 12-0a. The only difference is on the first part(one is 4-HS, while the other is PASN auth). However, i wonder if it's necessary to add such a figure 12-0b, as these two figure are totally same for the second and third part.

I recalled it's Mark's suggestion to add a new figure to describe the assignment of Device ID and PASN ID. Could you please give some suggestion on this😊

Best Regards！

李炎 Li Yan

标准预研工程师 Standard Development Engineer
架构团队/有线规划部/有线产品经营部 Architecture Team/Wireline Product Planning Dept/Wireline Product Operation

南京市雨花台区软件大道50号中兴通讯

ZTE Corporation,50 Software Avenue, Yuhuatai District,

Nanjing, P.R.China, 210012

T: +86 755 xxxxxxxx F:+86 15850568971
M: +86 xxxxxxxxxxx
E: li.yan16@xxxxxxxxxx

www.zte.com.cn

Original

From: GSmith <gsmith@xxxxxxxxxxxxxxxxxxx>

To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>;

Date: 2024年06月13日 05:09

Subject: Re: [STDS-802-11-TGBH] discussion on PASN ID figure 12-0b

Hi Joe, Li Yan,

Just checking -it’s not too easy to follow your to and fro.

Joe seemed originally to be asserting that the subsequent PASN authentications to the ESS after the initial one, should use the same MAC address and be called “re-associations”. I just want to check that this is not so. I remember checking with the FTM guys that a ‘requirement’ was that the STA wanted to know where it was but dd not want the ESS to know, i.e., the STA need not provide an IRM or PASN ID if it did not want to, but, in that case, it is essential that different MAC addresses are used by the STA for each authentication. Similarly, when that STA does want the ESS to know who it is (but does want to be hidden from nasty 3^rd parties), when using IRM, the IRM is different for each authentication, or, if using PASN IDs, each authentication uses a random MAC Address.

Also Okan has a proposal to add all the figures and descriptions in an Annex and delete the one in the main device ID text.

Best Regards

Graham

From: Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, June 12, 2024 12:36 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] discussion on PASN ID figure 12-0b

Hi Li Yan

Thanks for following up with me. Please see my comments response in-line below.

In summary:

Figure 12-0a provides a pure PASN device ID exchange.

Figure 12-0b provide a PASN device ID exchange for a previously associated non-AP STA which has a PASN ID (and therefore including the association and the establishment of the initial PASN ID). I believe this figure should focus on PASN behavior; hence the three parts should be association/obtaining a PASN ID from AP1, using the PASN ID (PASN ID1) without association with AP2 and obtaining a new PASN ID (PASN ID2), and then using PASN ID2 with AP1 (without association or reassociation) and obtaining a new PASN ID (PASN ID3). All of three of these parts should include an FTM Session, before deauth or disassociation.

If you or others think we should add a figure to show how device ID is used in association for a “returning non-AP STA” (see definition below), that should be a different figure and should not have any PASN exchanges. Also, if we add such a figure for device ID exchange, we may also want to add a figure for IRM exchange. But I’m not looking to add work and I don’t think we received any comments requesting such figures.

Regards,

Joseph

From: li.yan16@xxxxxxxxxx <li.yan16@xxxxxxxxxx>
Sent: Tuesday, June 11, 2024 10:25 AM
To: 000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx
Cc: jslevy@xxxxxxxx; yang.zhijie@xxxxxxxxxx
Subject: discussion on PASN ID figure 12-0b

Hi Joseph,

I really appreciate your comments on the figure 12-0b of my PASN ID contribution(789r3). If i remember correctly ,you pointed out such 2 comments:

1. in figure 12-0b, 4-way handshake should be started with association request/response

Yes, i will add it

[JL] – Great this will put the flow in the correct context, as it is my understanding that a PASN ID is provided during a 4-way handshake. So, association is required.

2. the second 4-HS should be reassociation and the non-AP STA can not use new mac address in this part. commenter wants to clarify the third part is for PASN ,so it needs to provide PASN ID in the 4-way handshake.

Firstly, i totally agree with you that non-AP STA should not use random MAC address and should not further use device ID feature in the reassociation case.

[JL] – as you affirm under the current random MAC “rules” a non-AP STA that is reassociating with the same ESS does not change its MAC address, it does however complete a new 4-way handshake after reassociation. Therefore, a reassociating non-AP STA has no need for device ID, as it has identified itself with its MAC address. However, I believe deferent “rules” apply for the case of a “returning non-AP STA”, a non-AP STA that previously was associated to the ESS that is using a “new” random MAC address to associate with an ESS that it had previously provided the non-AP STA with a Device ID. A “returning non-AP STA” may (should?) use the Device ID to identify itself to the ESS. Also, a non-AP STA that is using PASN (that is not associating with the ESS) that has be previously assigned PASN ID may (should?, shall?) use the PASN ID to identify itself in PASN exchanges. Note as PASN is an optional feature, it may make sense to require the non-AP STA to use a PASN ID when one has been provided. This doesn’t mean that the non-AP STA is required to use device ID to use PASN. However, if the non-AP STA has chosen to use device ID and PASN and has received a PASN ID from an AP in the ESS, then it (shall/should) uses the PASN ID.

Secondly i added the third part for 4-HS just to describe a case of reporting and providing a new device ID, which is an association case and is for data transmission(I know STA can do FTM during association, but in this figure, i just want to separate association part from PASN authentication part, which is used for data transmission and FTM session, respectively). My intention is as below:

1) provide both of Device ID1 and PASN ID1 in first part(4-HS)

2) report PASN ID1 and provide PASN ID 2 in second part(PASN authentication)

3) report Device ID1 and provide Device ID 2 in third part(as the reassocation is taken into consideration, i suppose to change the third part to associate with a new AP(AP3),which is used for data transmission with AP3, such as class 3 frame, instead of FTM session)

[JL] While this a valid use case and may occur the focus of this figure is to illustrate PASN functionality. I think it would be best to have:

an initial connection, which establishes an association, includes a 4-way handshake that provides a Device ID and a PASN ID., a data exchange and then the non-AP disassociates (it does not deauth). Note that if the non-AP STA does not disassociate then the part three is an exchange between an associated non-AP STA and the AP it is associated with. (There is no need for any additional security exchange, association, or reassociation as there has been no disassociation.) I believe PASN can be used while a non-AP STA is associated with an AP, to exchange information with another AP the STA is not associated with. In other words, a non-AP STA can be in State 4 with an AP and can be in State 1a with another AP at the same time, a non-AP STA can only be associated with one AP at any given time.
followed by a PASN exchange with AP-2
followed by a PASN exchange with AP-1 (the non-AP STA does not (re)associate, it only establishes a PASN relationship).

I also recalled Mark helped to clarify the third part(4-HS) uses association instead of reassociation. Maybe this is another option.

[JL] While this is true and may be useful to be shown in a figure, I don’t think this belongs in the figure describing PASN operation.

In summary , i would like change the figure as below:

a) add association frame exchange before the first part(4-HS) [JL] agree

b) add data transmission after 4-HS for the first part and third part [JL] agree with adding data transmission to the first part and third part. But for the third part not including a 4-HS, for the third part as I believe this should be a PASN exchange, basically identical to the second part, but using PASN ID2 and ID3.

c）in the third part, just use association instead of reassociation. or in the third part, non-AP STA associates with a new AP(i.e., AP3) for 4-HS [JL] As stated above I think the third part should be a PASN exchange (PASN ID2 in Auth Msg1 and PASN ID3 in Auth Mesg2).

the original figure is as below