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: 2023年4月18日 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.
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 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.
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.
- 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.
- 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.
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
|