| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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>
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 |