Re: [STDS-802-11-TGBH] IRM Points at Tuesday's meeting

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

Graham,

Sorry I wasn’t clear on a couple points. Let me try again/some more:

On the second paragraph, I had two points:

If the IRMK is not changed on _Re_assocation, then it is highly trackable by third parties. I was just to clarify, if in the text below where you said “When the STA associates” if you meant only Associates, or really meant (Re)associates.
On the second point (b), I was noting that the original proposal (and I think is still in this new proposal with the “fixed” offset) is that the Check is derived by doing XOR operations on bits of the Key. But, it seems that with the fixed offset rule in place, there is really no point in the Check being derived from the key, at all. It is just additional “stuff” associated to the key (could even just be some bits in the key) statically, and it might as well not take any computation at all.

Mark

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 19, 2022 12:49 PM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] IRM Points at Tuesday's meeting

Thanks Mark, responses below.

From: mark.hamilton2152@xxxxxxxxx [mailto:mark.hamilton2152@xxxxxxxxx]
Sent: Wednesday, January 19, 2022 12:48 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] IRM Points at Tuesday's meeting

Thanks for this, Graham.

I have two follow-on points/questions:

On your first paragraph, and that IRM would (might) not be used in a 10,000 seat stadium: I’d just like to clarify that the devices would still randomize their MAC address (to not be tracked) and that could be done with IRM, but with the “IRM Indicator” set to 0 for most devices. That is, most of the users have no reason to provide any identity to the stadium, and probably don’t/won’t trust what the stadium would do with it and would want to disable IRMA on that network anyway. Are there advantages to having IRM enabled, but rarely used? For example, a few devices (staff, vendors) might actually provide a identity (although this is likely handled with a separate SSID, actually). But, if there would be any advantages, I *think* that enabling IRM but having very few devices participate would remove the burden on the APs, right?

GS – Yes, the STA can still advertise support for IRM and set the IRM Element Indicator to “Private”. Then the MAC address is simply a randomized one. The other point was that if the APs did not advertise support for IRM then the STA would not use it anyway and would simply be using RMA. Also, as you point out, even if the APs did show support, then I suspect that the STAs would choose to use “Private” anyway (but if the network did advertise support for IRM, then it has to be assumed it has the power to do so). Having said that, if identification was useful, then the ID Query part might be used (special privileges etc.) and the STA indicates “Private/ID”.

On your second paragraph, and the IRMK Check offset: If we proceed with a constant/a priori offset, doesn’t that turn the Check value into a simple (non-unique) “identifier of the identifier”? We would need to consider:

Does this make devices more easily trackable again, by introducing a constant identifier that can be tracked on every re-use? (I’m assuming that the “new key with every association” is not at every _Re_Association, is it? So, while the device is associated to the network, but moving between APs within the stadium, they can be tracked? Is that a big deal?)
Is there any advantage in this Check being derived from the key via some algorithm, versus just being an extra “token” that is stored along with the key, and the AP just does a straightforward search/lookup (no arithmetic at all)? In fact, this then devolves into just being a few extra bits of the key itself, I think.

GS –

Every association the IRMK is changed. If re-associating by moving around, if the Check was the same, then yes it would indicate it was the same STA that was associated to the network, but then it is known that a STA is associated and no knowledge of who it is. It would not, however, give any more information as to the key which would happen if the offset changed each time. How bad is this? It is bad as a spoof can copy the IRMA, Hash and Check.

If the ESS is managed such that other APs know the IRMKs of associated STA, then the Check need not be used?

The way round this, however, is simple. The STA can re-associate with a new Address (IRMA) and Hash but does not include the Check. The AP would then simply ask for the Check once associated (IRMK Check Request) et voila!

Interesting idea on the ‘algorithm’ . It would need to be that the algorithm gives a different answer for the same key? Perhaps I don’t fully understand, can you give an example?

Mark

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 19, 2022 10:17 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] IRM Points at Tuesday's meeting

Dan brought up a couple of good observations after my presentation on the IRM/ID scheme.

Dan was concerned that in the case of a stadium there could be 10’s of thousands of devices which would put a big burden on the AP/Network in calculating the hash and finding the key (IRMK). This would be true but on reflection I now realize that this is not a Use Case that TGbh has considered and also I doubt if it would be. In this case I suspect that the APs would not indicate support for IRM and hence the STAs would not use it. The ID Query might be used, not sure. Still it’s a good point and I do want to make sure the effort is kept a low as possible.

The idea of the IRMK Check was to reduce the work by the AP.

The IRMK Check at the moment uses a random start bit. Dan expressed that it was still a lot of work for an AP to go through all the IRMKs and perform the 16/8 bit EXOR at the point that the STA is associating. There was a suggestion that a fixed offset could be used and on reflection I think this is a practical solution. When the STA associates, it provides a new key (IRMK) and if we had a fixed offset, the AP could quickly calculate the 8 bit Check and store it with the key, i.e., it stores the 9 octet key and 1 octet check, 10 octets per STA. Then when the STA indicates the Check, the AP has a simple job to find those keys that match the check (reducing the list by a factor of 256).

As an aside to this, I did at one time consider using a CRC-8 as the check. I am not an expert on this but I felt that that was more work – I may be wrong, so if anyone feels that would be better please let me know.

Thanks

Graham

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