| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
On 4/10/23, 10:38 PM, "Zhijie Yang (NSB)" <zhijie.yang@xxxxxxxxxxxxxxx> wrote: Hi Dan, Thanks for the comments. I quickly check the gramma, I see “opaque” can be adj., verb or noun.
https://www.google.com/search?q=opaque Not a verb. I think current agreement is that the device ID is encrypted in the frame, and thus the device ID become opaque in the air. It’s due to the implementation on how the network generate the device ID, one example is the annex Z. That’s all.
We don’t need to stress “a different mechanism that provides it affords comparable security and privacy”, even the network generates a device ID like 111,222,333,etc. it’s still safe as this part is encrypted. I don’t understand what’s the meanings of “opaque identifier when it’s constructed from Annex Z”, do you intend to say “double opaque”( opaque identifier + encryption) for the 3rd party?
Well I never actually said "opaque identifier when it's constructed from Annex Z" so maybe ask the person who said that for clarification. But "double opaque" is doubly confusing.
I think this boils down to a fundamental misunderstanding about what we are trying to accomplish with this amendment. The intent, when we added Annex Z and the device ID assignment KDEs to the 4way handshake, was to use these identifiers
in other exchanges—SAE, FILS, PASN, whatever—where the identifier would be sent outside of the 4way handshake. We just haven't gotten around to using them in these other exchanges. And that's why the security and privacy afforded by the technique in Annex
Z is important. If one did not follow Annex Z and came up with a scheme that did not have comparable security and privacy then the use of the assigned device ID in these other frames would allow for tracking which would be wrong. You seem to think that the device identity is provided in the 4way handshake and since that's protected then there is no additional obfuscation necessary for the device ID. But if device IDs were just to be exchanged in the 4way handshake
then there's no point in sending them. The 4way handshake is post authentication. So the device must already have been identified by the credential it used to authenticate. What is this additional identity being provided for? The issue isn't whether it's "safe"
to assign 111, 222, 333 as device IDs to a STA during the 4way handshake. It's pointless. "Hi I'm 111, oh, so you're telling me I'm now 222? OK….hi I'm 222, oh, so you're telling me I'm now 333? OK…" That solves zero use cases. The STA has an identity. That identity is a long-term identity. It isn't 111 or 222 or 333. The procedure from Annex Z will turn that long-term identifier into something that the STA can use in a subsequent exchange, outside of the 4way
handshake, that still affords the required security and privacy. The AP gets this opaque identifier in this other, subsequent, exchange (which is not the 4way handshake) and is able to use the procedure from Annex Z to recover the long-term identifier by which
the STA is known. That is useful. Now if you don't want to use the procedure from Annex Z you can do something else, *provided it affords comparable security and privacy.* But you can't just send 111 or 222 or 333 and expect that to be useful in a subsequent
exchange. 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 Thanks Best Regards Jay Yang From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Jay, "opaque" is not a verb, it's an adjective. I think this sentence is better: "An opaque identifier can optionally be constructed by the network using the procedure in Annex Z or can employ a different mechanism provided it affords comparable security and privacy." and if people are getting hung up on the word opaque we can add a definition of it for the terms portion of the amendment. 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 4/10/23, 6:21 PM, "Zhijie Yang (NSB)" <zhijie.yang@xxxxxxxxxxxxxxx> wrote: Hi Mark, For CID35, I like what the commenters suggested sentence, and thus we can add one Note to say: Note1: An device ID shall be constructed by the network, e.g., the example procedure in Annex Z, in which the device ID is opaqued over the air to the 3rd party. Thanks Best Regards Jay Yang From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
All, Just a note that I have uploaded my proposed agenda for the TGbh call Tuesday morning (U.S. time):
11-23/0621r0. My general plan/approach is:
-
Review the latest updates to the IRM proposal that we’ve been discussing, and see if we agree the requested updates are done and we can reach consensus on this way forward.
-
Review the proposal from Okan on PASN (with Device ID). Is there consensus to add this material? (I believe that between Graham’s IRM updates for PASN, and/or this proposal for PASN, we now cover CIDs 19 and 20.)
-
Review/discuss my suggestions for CID 35. ( @Dan Harkins and
@Amelia Anna Matilda Katarina Andersdotter, if you can be on the call to help us conclude on these, it would be helpful, thanks!)
-
Based on the outcome of the above, give instructions to produce the updated comment resolutions list that we can motion next week. I am hopeful that the above discussions can reach consensus on the call, and our motion next week will be able to close off all the open comments, and Carol can get going on an updated draft. If anyone has concerns with the resolutions above, please prepare your thoughts for a discussion tomorrow that will get us to a conclusion. Thanks. 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 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 |