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

Re: [STDS-802-11-TGBH] Agenda for TGbh April 18 teleconference



Hi Jarkko, all,

 

For the second point, the synchronization issue is main concern for device ID among APs in larger scales network. For some mobility STAs, they may reassociate with different APs and proceed with 4HS each time when they move from one place to another.

E.g. AP1 assigns device ID1 to STA1 when STA1 stays in location A and associates with AP1. After that, the combination of STA1 and device ID1 will be synchronized to the whole network, so that other APs in the same ESS can recognize STA1 when it provides device ID1. And then the STA1 moves to locate B, and reassociate with AP2 and performs 4HS again. If we define some rule to say AP2 must assign a new device ID to STA, the new combination of STA1 and device ID2 will be synchronized to the whole network again.  Such approach will cause a huge synchronization job on network side. I believe some network vendor will prefer the single device ID for each STA(or the device ID is not frequently changed) to reduce the synchronization efforts.

As the group agree the device ID is only exchanged in the encrypted frame, there is no security issue if the STA use the same device ID.

Of course, if some member propose the device ID can be exposed in the air, I see the value that the new device ID must be assigned in 4HS.

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 2023418 8:14
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Agenda for TGbh April 18 teleconference

 

Hi Mark and Graham. 

 

Thank you Graham for accepting the proposed NOTE. It would be great if we can add this clarification. 

 

On the second point, for your first bullet item (clearly define how the non-AP STA interprets this), I note that the case you cited where the zero-length Device ID is returned also has the explicit statement that the Identifier Status is set to “Recognized”.  The next paragraph (which you didn’t quote) discusses the case when the AP sets the Identifier Status to “Not Recognized”.  So, the non-AP STA can tell which situation this is.

 

For your second bullet item (recommend to change the Device ID with every 4-way), I don’t personally have a strong opinion.  We could remove the option for the AP to not send a new device ID, of course.  I believe some members thought this was overly prescriptive, however.  We could make such a suggestion in a NOTE (or “should” language), if you have a proposal for that.  Or, we leave it to the implementation decision.



Having said that, I have no objection to the Jarkko’s extra note.

 

On the second comment, the main point is to clarify what the empty Device ID in the fourth message of the 4-way handshake means. There should be text to say that STA continues to use the old Device ID for instance.

 

Thank you for not having objections for the note. 

 

Cheers,

Jarkko 



On Apr 17, 2023, at 3:31 PM, G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

 

Hi Jarkko and Mark,

Yes I agree in principle with Jarkko’s comment and also what Mark observed, i.e., although the non-AP STA could use the IRM address in probes I agree it should not unless it wants to be identified (I was thinking that if in the vicinity and ready to associate it might be OK).  However, I tried to cover this in the text.

 

The following is in the 23/0129r5.

“ A non-AP STA may use that address for direct or broadcast probing for an AP or ESS that was allocated that address, such that the AP may identify the non-AP STA and note that that particular non-AP STA is within range of the WM, but only if the non-AP STA wants to be identifiable at that time. 

 

Having said that, I have no objection to the Jarkko’s extra note.

 

Thanks

Graham

 

From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx> 
Sent: Monday, April 17, 2023 5:47 PM
To: 'Jarkko Kneckt' <jkneckt@xxxxxxxxx>; 'Lumbatis, Kurt' <Kurt.lumbatis@xxxxxxxxxxxxx>; G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Agenda for TGbh April 18 teleconference

 

Hi, Jarrko,

 

Thanks for getting concerns out before the call…

 

Since you seem to have asked my personal opinion (as well as Kurt’s and Graham’s), here are my comments:

 

On the first one, it would be helpful if you can cite where in 802.11 it defines that a non-AP STA uses random MAC address in Probes and ANQP queries.  The only thing I can find is in 12.2.10, first paragraph, which states (my highlights, of course):

MAC privacy enhancements are enabled on a non-AP STA when dot11MACPrivacyActivated is set to true.

The STA shall periodically change its MAC address to a random value while not associated to a BSS. The STA

shall construct the randomized MAC address from the locally administered address space as defined in

IEEE Std 802-2014 and IEEE Std 802c™-2017. However, the non-AP STA shall not change its MAC address

during a transactional exchange, for example, transmitting Public Action frames for preassociation discovery,

or during the creation of state on an AP using preassociation capabilities, for example, RSN preauthentication

or FT over-the-DS. The smaller the period of MAC address change, down to a single transmitted frame per

MAC address, the greater the privacy these enhancements afford. The actual period used when changing a

MAC address is implementation dependent and outside the scope of this standard.

To me, this is very not specific about the timing of the address change, and it could be, for example, that when the implementation decides the address has been used enough to possibly allow it to be tracked/compromised, the non-AP STA can change it by associating or doing PASN-authentication with a new (random) address. 

 

I don’t, personally, object to your added NOTE, but I would add that the IRM MAC Address could be used for other frames (not only association/authentication) as long as the implementation is limiting the exposure to a “reasonable” amount (implementation choice) before changing it.  Perhaps we can soften the NOTE a bit?  Perhaps we should add to the NOTE that the IRM MAC address should only be used in pre-/non-associated frames when it is important/useful for the non-AP STA to be identified, which probably implies most Probes, ANQP requests, etc., can use a non-IRM assigned random address.  That could be clarified/emphasized to help with this concern.

 

On the second point, for your first bullet item (clearly define how the non-AP STA interprets this), I note that the case you cited where the zero-length Device ID is returned also has the explicit statement that the Identifier Status is set to “Recognized”.  The next paragraph (which you didn’t quote) discusses the case when the AP sets the Identifier Status to “Not Recognized”.  So, the non-AP STA can tell which situation this is.

 

For your second bullet item (recommend to change the Device ID with every 4-way), I don’t personally have a strong opinion.  We could remove the option for the AP to not send a new device ID, of course.  I believe some members thought this was overly prescriptive, however.  We could make such a suggestion in a NOTE (or “should” language), if you have a proposal for that.  Or, we leave it to the implementation decision.

 

Mark

 

From: Jarkko Kneckt <jkneckt@xxxxxxxxx> 
Sent: Monday, April 17, 2023 3:14 PM
To: mark.hamilton2152@xxxxxxxxx; Lumbatis, Kurt <Kurt.lumbatis@xxxxxxxxxxxxx>; gsmith@xxxxxxxxxxxxxxxxxxx
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Agenda for TGbh April 18 teleconference

 

Hi Mark, Kurt and Graham, 

I have two comments on the material that are part of the motion. The comment 1 was explained in my earlier emails. 

It would be good to solve these issues before the motion. 

 

Cheers,

                Jarkko 

 

1) 129r5 IRM

                - Currently 802.11 defines that a non-AP STA uses random MAC address in the Probes and ANQP queries that it sends in the pre-associated state. 

                - IRMA allows STA to use the IRM MAC address in probes and ANQP queries. This is not following the guidance of the 802.11. 

                - If the IRM MAC address is used in probes and ANQPs prior authentication and association, then an attacker can learn the IRM MAC address and the attacker may use the IRM MAC address to authenticate as the victim STA. 

                - 802.11bh has no limitations or recommendations for the network security, in some networks the attacker may steal the STA identity by authenticating to the BSS. The AP even tells to the attacker whether the device id was successfully stolen.  

 

Recommend resolution: Please add the following note to clause 12.2.12.2:

“NOTE: In States 1 and 2, the IRM MAC address is recommended to be used only in authentication and association frames. 

To ensure good STA privacy, a non-AP STA is recommended to change its IRM MAC Address in every 4-way handshake."

 

 

 

2) 1329r17 allows AP to send a zero-length device ID in the 4/4 message of the 4-way handshake. There is no description what does this zero-length device ID means to the non-AP STA. 

                - Does this mean that STA has no device ID with the AP? Or does the STA continue to use the old identifier in the next authentication/association. This should be clearly defined. 

                - I recommend to change the Device ID after every 4-way handshake. This complicates device ID use to track the STA. 

 

<image001.png>    

 

On Apr 17, 2023, at 11:07 AM, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:

 

All,

 

I have posted a proposed agenda for the April 18 TGbh teleconference, here: https://mentor.ieee.org/802.11/dcn/23/11-23-0653-00-00bh-agenda-tgbh-2023-april-18.pptx

 

REMINDER: This includes consideration of a motion to approve the “Ready for motion” CIDs in our comment tracking spreadsheet, here: https://mentor.ieee.org/802.11/dcn/22/11-22-0973-23-00bh-cc41-comments-against-d0-2.xlsx , which would approve these CIDs: 

  • CIDs 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 15, 16, 17, 24, 25, 26, 27, 30, 31, 32, 33, 36, 40, 41, 42, 45, 47, 49, 50, 51, 52, 53, 58, 61, 62, 63, 64, 65

 

Please come prepared to consider this motion.

 

Work will then continue on the (3) remaining CIDs.

 

Thanks.  Mark


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-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1