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

Re: [STDS-802-11-TGBH] Opaque ID, PASN



Hi all,

 

Graham, very nice summary! I hope it helps others as well.

 

Not to repeat you, but to emphasize,

 

- Option 2 seems to work with or without opaque ID:

*if AP/ESS is okay with changing device ID every time (i.e. each FTM session and\or return to the ESS), it does not have to use opaque ID, since the generated device ID used only once by the STA in PASN Auth M1

*if AP/ESS is not okay with changing device ID every time (i.e. each FTM session and\or return to the ESS), it can use opaque ID derived from device ID.

 

- Option 1 or Option 2 aims at “device ID support for PASN”, i.e. AP/ESS is in control, as in current device ID idea (network generated device ID). If a STA wants to be in control, it can use IRM for PASN (Thanks Graham for underlining this)
(note: device ID for PASN can be constructed for “STA generated device ID” but, yes, it would be a different scheme and need more time and thinking to come up with details)

 

- Regardless of Option 1 or Option 2, the non-AP STA activates (or not) device ID in PASN Auth M1.

 

BR,

Okan

 

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: 2023
420 0:07
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Opaque ID, PASN

 

Hi Jay,

What you propose I think changes the opaque ID as per Annex Z quite significantly.

 

Just to make sure I understand Annex Z, here is (basically) how I think it works (I am sure Dan can correct me if I have misunderstood). 

 

  1. AP/ESS select a key k, shared throughout the ESS
  2. AP selects an ID
  3. ID is padded with X+1 octets, the first octet has value 0x0X, the rest are 0x00
  4. The padded ID is then preceded by an 8 octet tweak (to prevent duplications) 
  5. Hence, if X = 4, then the tweaked, padded ID is 13 octets plus the ID.
  6. This is then passed to AES-SIV using key k, this produces the “opaque ID”

 

  • Decoding strips off the tweak and padding, leaving the ID.
  • By changing the value of X, and hence the padding, a new opaque ID is produced, but still decodes with the same ID

 

So, as written, the non-AP STA has no work to do.  It may receive a different opaque ID (assuming X was changed), but when sent back to the AP it is decoded to be the same ID.

 

If we now follow Oran’s Option 2 PASN scheme, then

  1. in first PASN, STA sends nothing in msg 1, but AP sends an ID1 in msg 2 (because STA indicated it is using device ID).
  2. In next exchange, STA sends ID1 in msg 1, AP recognizes STA and sends new ID2 in msg 2.
  3. Etc.

It works, and is private, as long as a new ID is provided every exchange (because ID is sent in the clear by the STA)

 

If AP does not want to change the underlying ID, then it can use the opaque version:

  1. in first PASN, STA sends nothing in msg 1, but AP sends an opaque ID1 in msg 2 (because STA indicated it is using device ID).
    1. For example, opaque ID uses X=4
  2. In next exchange, STA sends opaque ID1 in msg 1, AP recognizes STA and sends new opaque ID1 in msg 2.
    1. For example opaque ID now uses X=3
  3. Etc.

In this case of using opaque ID it means that although it is the same underlying ID, the opaque ID, sent in the clear by the STA in msg 1, is different each time.

The AP/ESS does all the work.  It works because all APs in the ESS know the key k.  This is a classic example of how to use opaque ID.

 

If, as you suggest, the non-AP STA generates the opaque ID, then the key k has to be known to the STA and to each AP in the ESS.  I don’t think that is an easy task? Is the pre-shared key the same across the ESS?

Assuming that a common key is available/known, then the scheme would be:

  1. in first PASN, STA sends nothing in msg 1, but AP sends an ID1 in msg 2 (because STA indicated it is using device ID).
  2. In next exchange, STA sends an opaque version of ID1 in msg 1, AP recognizes STA and does not send anything in msg 2 (maybe a “I recognize you”)
  3. In next exchange, STA sends a new opaque version (different X) of ID1 in msg 1,
  4. Etc.

 

This is not device ID at all, it is a different scheme.  It might be better to simply invent a new scheme where the STA sends a new ID every time in msg 1.  But this is effectively what IRM is doing.

 

So, after all that, I think that Oran’s option 2 works and it is up to the AP whether to use opaque ID or not. 

 

To cover Jarkko’s point about preferring the STA to control, that is covered by the IRM version.

 

Sorry such a long email but I am trying to make sure I cover everything, and hopefully help others.

 

Best regards

Graham

 

 

 

 

From: Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Tuesday, April 18, 2023 10:48 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Opaque ID, PASN

 

Hi Graham,

 

Thanks for initial this mail loop.

 

I’m thinking can we make the implementation more flexible for network vendor as Device ID features simple solution?

 

One approach is AP give the device ID, and STA has the pre-shared key and encrypt it by itself when sends it in the air. Such direction will address the synchronization efforts on network side if some member have some ideas on this.

Another approach is the AP give the encrypted ID/opaque ID, and the STA can use it directly. But the network need to provide a new opaque ID each time.

 

If some network vendor intends to adopt Annex Z, I can image there will be an Agent entity deployed in the network to dedicate on opaque ID generation and identification, but the 11bh SPEC don’t define anything on how the authentication to communicate with the Agent entity. I’m not sure how many efforts we need spend to make this part stable if we walk on this direction.

 

How about rewording it like this:

The allocated Device ID should be encrypted and become opaque in the air when STA transmits the first PSAN frame, e.g. The STA may send the opaque Device ID generated by Annex Z in the first PSAN frame.

Meanwhile the AP shall grant a new protected Device ID in each PSAN session. 

 

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: 2023
418 23:55
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Opaque ID, PASN

 

It seems from today’s meeting that the general feeling was that if we want a PASN solution for Device ID, then option 2 was looked upon more favorably. 

A question over option 2 is whether opaque ID is used, or must be used, or not.  As far as the STA is concerned it makes no difference as it is entirely controlled by the AP/ESS. 

In either case the OTA ID in msg 1 has to change every exchange and also the AP must provide a “new ID” every time in msg 2.

 

I think we need to first sort out the opaque question CID so that we are on the same page as to when and how the AP uses the opaque ID. 

Hence I suggest that before we again discuss device ID/PASN, we first settle on language to cover the opaque CID.

 

As Jarkko pointed out the STA has no idea or input on this and I think that has to be clear.

May I propose the following text as a starting point

 

“An AP may allocate the Device ID in an opaque form.  Then, if for any reason the non-AP STA sends that Device ID in an unencrypted frame, the underlining device identification is private (opaque) from third parties. The AP can use the procedure in Annex Z, which affords the required security and privacy, to protect the device identification within a Device ID.

NOTE: If the AP is allocating an identification that has external meaning (a username, account number, etc.), it may choose to allocate the Device ID in an opaque form. 

 

If we have this text in place, I suggest it then gets easier to define the option 2 PASN  method.

 

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


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