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

Re: [STDS-802-11-TGBH] ID encoding

Hi Jouni,

Been looking further into the ID encoding presentation and I am asking myself what is really different to the IRMA proposal?

Note:  Sorry if this is too long, maybe I will prepare a presentation and it could be discussed properly at the next TGbh telecon. Anyhow this gives you advanced knowledge of my thoughts.

_________________________________________________________________________________

 

The ‘identity’ part is contained in an IE in both schemes.

 

This field in the IE is encrypted in both with a keyed hash.  In IRMA it happens to use the random MAC address as one input -  it’s a random number so seems sensible to use it.  Using the SSID is fixed so there is no advantage there. The temporal element is in both (if it is needed as copying does not now appear to be that important according to TGbi as I covered in my previous email).

 

Both use a key shared by STA and AP.  In IRMA the key is provided in the 4 way HS, and can be provided by the AP or the STA (probably we would choose the AP version).  In ID encoding the key is derived in the 4-way HS but it is not clear if it is different every association (I assume that it is, but you said something in your presentation that made me wonder). 

 

I am not sure what in ID encoding scheme the AP and the STA are saving but I assume it will the ID and the key. That assumes the ID actually means something.  In IRMA they simply save the key. 

 

I struggle to see why the ID encoding scheme is in essence any different from IRMA.

IRMA has the required details such as adding to the IE the “known”, “unknown”, “private” indications plus the optional field to reduce the work of the AP when searching for the STA.  But these could be added to ID encoding. 

 

Unclear how much work required in ID encoding if AP has 1000 STAs?  In IRMA it can be reduced to searching through just a maximum of 4, 2 on average using the IRMK Check field.

 

The major difference seems to be that the ID itself may be a permanent thing, but don’t we have Device ID to do that?

 

Anyhow, I can’t see how ID encoding provides anything over IRMA.  Perhaps IRMA could use the per-STA key derived in the 4-way handshake rather than simply using a KDE but other than that I can’t see why this scheme should be preferred over IRMA.

 

Maybe the schemes could be merged, but I don’t personally see the need for a permanent ID to be used as once the STA is identified, it is known.  IRMA works well in combination with Device ID which is a cleaner way of doing it.

 

Having said all that, as I have previously noted, the much simpler MAAD scheme works just as well and does not require all the computations.

 

Anyhow, would welcome responses to make sure I have understood ID encoding sufficiently.

 

Thanks

Graham

               

 

 

From: G Smith
Sent: Monday, November 21, 2022 10:13 AM
To: Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: ID encoding

 

Hi Jouni,

Thanks for your presentation 22/2013r1. have the following comments:

 

  1. Unclear who allocates the ID.  Does non-AP STA allocate or AP, or both?
    1. If both advertise support and non-A STA does not include ID IE  in request, does AP include ID IE in the response?
    2. Can non-AP STA allocate?  If non-AP STA includes a “not recognized” ID IE we are back to the discussions that have plagued Device ID.
  2. Then, how is ID changed?  Presumably it needs an ID IE from the AP or does the non-AP STA control?
  3. If the IE is not encrypted then there is no difference to the MAAD scheme except  I can’t see any advantage in adding an IE which acts as an identifier.  In fact, this could be construed as a fingerprint for this STA.  In MAAD the MAC address appears random even though identifiable by one AP. The mere presence of the ID IE clearly sets the non-AP STA apart. 
    1. Non-AP STA could I suppose include a dummy ID each time, as if not, it identifies clearly which APs it is interested in, encrypted or not.
  4. Encrypting the ID means that the STAs need to store the ID and the key for each connection, plus the need to carry out the computations each time , plus noting the timestamp from the beacon, assuming that it can get the request on the air before the next beacon. But, need to ask for what purpose encrypt?
    1. In TGbi I had a lot of push back on the ‘paparazzi attack’ with what appeared to be a general view that protection to this was not needed. If so, then MAAD works fine as is and the idea that somehow an attacker copies the MAC address and then uses it to ‘fool’ an AP is moot.  In fact, as I have pointed out numerous times, “so what”, even if this does happen, the bandit can’t associate anyway so why waste time adding computations and complexity? 
    2.  So, what “replay  frames” or “cloning” problem is the need to encrypt addressing?   In practice it is not a problem (can’t associate anyway, and it seems that this attack is not of interest anyhow) and hence does not merit adding computational complexity.

 

Will this scheme work – yes

May this be of interest to TGbi - maybe

Does it have any real advantage over MAAD in the TGbh context – No

If this ID IE is only included when addressing an AP to which it wishes to be pre-identified, then it is an obvious giveaway.  With MAAD, for example, there is nothing to show that this AP is special. 

 

Finally I would like to note that TGbh is looking for easy to implement solutions to quickly address the Use Cases broken by RCM.   How quick and easy to implement is this scheme compared to MAAD?  - for me, MAAD wins easily and is a TGbh solution.   

 

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