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