| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Thanks Mark, good questions, Responses again below. Graham From: mark.hamilton2152@xxxxxxxxx [mailto:mark.hamilton2152@xxxxxxxxx]
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. GS – Yes, if the IRMK is not changed on a Reassociation (and as you pointed out, it should not be), AND an IRMK Check is repeated, then it is trackable ONLY IF
it uses the same IRMK Check (which it will). The same Check is the giveaway. The IRMA and IRM OKM changes so it is not trackable if the IRMK Check is omitted. On Association, i.e. an Association Request, the IRMK changes. Hence, the idea that on a Reassociation,
the STA does not include the IRMK Check. The AP asks for it once associated.
-
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. GS – Aahh…I see. What you say is simply add 8 random bits as an “IRMK check or identifier”? That’s a point and then the 8 bits become part of the stored IRMK.
So we would have a 80 bit key and we give away 8 bits. That’s almost where I started on this and decided it was better not to give away any actual bits. The 8 bit EXOR can be carried out by the AP as soon as it gets the key and stored with it (so it stores
10 octets”, 9 for the IRMK and 1 for the Check) but the Check does not actually give away any bits, there are 256 combinations of the 16 bits that will satisfy the check. So they are almost the same and I could be persuaded to go with simply adding 8 random
bits if it made life that much easier for the AP. Mark From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Thanks Mark, responses below. From:
mark.hamilton2152@xxxxxxxxx [mailto:mark.hamilton2152@xxxxxxxxx]
Thanks for this, Graham. I have two follow-on points/questions:
1)
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”.
2)
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:
a.
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?)
b.
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 –
a)
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!
b)
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>
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 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 |