| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Graham, You're right that the device ID needs to be useful but it also needs to be untrackable by a 3rd party. That's what annex Z is supposed to do: make a way for a usable device ID—which could be, as you note, a membership number
or reference number—to be protected so that the device that uses this ID (this membership number or reference number) over and over as it connects and reconnects can't be tracked. But to do this we need to "opacicize" (pardon me) the ID before it is sent in the KDE. Yes the KDE is encrypted in the handshake so this ID is protected from passive observers but the entity receiving the network-assigned ID does not
get the cleartext ID at the end of his handshaking with KDEs. If it did, it would be the responsibility of the device to "opacicize" the ID before being sent back to the network and how could it do that unless it knew the secret the network uses to protect
IDs? If devices knew this secret they'd be able to decrypt other device's opaque ID blobs and that defeats the whole "do not track" motivation.
So it's not that there's 2 opaques. The useable device ID is not something given by the network back to the device. The device might know it (it's the membership number after all!) but the device is not responsible for "opacicizing" its
ID, the network is. So even though the KDE containing this opaque ID is, itself, effectively opaque due to encryption that's just the way it has to work in order to satisfy all those security requirements.
regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 8/16/22, 3:08 PM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote: Hi Mark, Aha, there’s the difference. I read Annex Z as an Opaque ID being one step extra to a “standard” ID. The Opaque ID in Annex Z is effectively a random sequence of bits that needs a further step of decryption before
it is useful. The Device ID in the KDEs could be an ID that actually has some meaning and does not need a further step of decryption.
As I stated at the meeting today, we are forgetting that the ID should actually mean something. Just knowing that a non-AP STA has returned means nothing – it’s what the higher layer does with it that matters.
In many cases the ID could be a membership number, a reference number, etc. Anyhow, that is where I am coming from, and I feel that there is a confusion introduced by having two “opaques”. I am quite happy with Annex Z describing this extra secure, “opaque ID”, but it should be distinguished
from the general term of what is actually inserted in the KDEs, e.g., an NGID is carried in the KDE, which may or may not be an opaque ID. Be interested if others are on the same wavelength, or maybe I am out-to-lunch. Best Graham From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Graham, I understand your point about “two opaques”. I never thought of that as a term that means the one in Annex Z, though. I’ve heard a couple similar comments on calls about this Annex, and it confuses me. Note that
the Annex is explicitly an “Example opaque identifer”. This is one (example) scheme for generating an opaque identifier. It could just as easily be an “Example NGID”, as our example for generating NGIDs. However, (and back to your point about “two opaques”)
it does also have an additional attribute that the ID this scheme generates is protected/opaque, even if the ID is passed off to a third party. To me, that is an interesting additional attribute, but has nothing to do with (or is an unrelated addition to)
the “Device ID” being opaque (to third parties) due to the way we implement our protocol exchanges.
But, perhaps I am alone in this way of thinking? Mark From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Understood (I re-read the email exchange) but we can’t have two “opaques”. The ID itself need not be opaque and the “opaque” version, as per the Annex, is specific. Encrypted is not “opaque” in my opinion.
I liked the original name “network generated ID”, NGID.
Anyhow see what others think, but I agree that “Device ID” needs to be changed. Graham From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Graham, This was discussed a bit on the reflector with Antonio (see emails on July 27). I think we have agreement that it must be opaque to third parties. So, it seems to be a question about “opaque in what context?”, and what does the group think about the best phrase that captures the answer to
that question. Other comments/thoughts? Mark From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
-
“Persistent Opaque Identifier (POI)” I was under the impression that the “opaque” bit is optional. Hence I don’t think I could support this.
Maybe “PSI” for “Persistent Identifier” or “PSID” or “PID”?
Graham From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
All, Antonio has proposed on the reflector (and I failed to bring up for discussion on today’s call), the following as resolution to CIDs 12 and 58 (and I think CID 25): Replace “Device ID”, “opaque identifier”, “identifier”, etc. (all the various phrases we currently have for this concept) with:
-
“Persistent Opaque Identifier (POI)” Note: Detailed and specific changes to be made to the draft will need to be provided. Please respond if there are concerns with this direction. I will formulate a motion for our August 30 teleconference in this direction, unless there is concern. Mark 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 |