Re: [STDS-802-11-TGBH] Any further discussion on proposed resolution to

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

Hello everyone,

I’m sorry that I had to leave yesterday’s call before this discussion came up. I hope that these comments aren’t irrelevant.

My viewpoint goes back to the initial problem statement, which I’ll paraphrase here:

Many APs and associated back-office systems had used a device’s MAC address as a proxy for a unique identifier of the device, and by extension, a user.

When devices began using RCM to improve privacy, the AP no longer recognized those devices or, by extension, those users which had ripple effects into the back office systems and the services they offered.

I see three cases of solutions from our extensive discussions. In the brief descriptions below, I tried to use the term ‘MAC address’ for the item exchanged during association that was historically a device’s MAC address, and ‘ID’ or ‘identifier’ for a piece of information that is used to identify the device (which could be a MAC address but doesn’t have to be one). I avoided the term ‘opaque’ which seems too confusingly vague (to me at least).

A device always presents a random MAC address with no intrinsic information to an AP, but during 4-way handshake/authentication the protected exchange of a separate ID from the device to the AP allows the device to be connected back to at least its history from a previous visit to that AP.

Storage: Device side: list of ID(s) linked to SSID/AP(s); AP side: list of devices linked to IDs

Pro ? allows an AP to connect a device to a previous visit/authentication to support various services; does not degrade privacy from the RCM improvements.
Con ? a true random MAC address means a device is not recognized until a secure association is set up so that the ID exchange is protected. Any pre-association use cases will not work.

A device predetermines at least one random MAC address with an AP during an association for later use. When the device returns to the AP, the device uses one of the previously determined MAC addresses during association. The AP has a table that connects one or more predetermined MAC addresses to a previous visit by that device. The device has a table that connects one or more predetermined MAC addresses to a specific SSID/AP for later use.

Storage: Device side: list of MAC Address(es) linked to SSID/AP(s); AP side: list of devices linked to MAC addresses

Pro ? allows an AP to connect a device to a previous visit/authentication to support various services; provides no opportunity for a 3^rd party watcher to connect the device with a previous visit, as long as at least one new MAC address is always ready for the next association and as long as the RCM algorithm is well-designed; pre-association use cases are supported.
Con ? the device is dependent upon the RCM algorithm being sufficiently random

A device predetermines at least one encoded MAC address with an AP during an association. The encoded MAC address might be essentially an encoded version of the device’s original MAC address or it might encode some other identifier. When the device returns to the AP, the device uses the previously provided encoded MAC address when it associates. The AP has a table that connects the provided encoded MAC address to a previous visit by that device.

Storage: Device side: list of identifiers linked to SSID/AP(s); AP side: list of devices linked to identifiers (encoding/decoding could be separate step)

Pro ? allows an AP to connect a device to a previous visit/authentication to support various services; provides no opportunity for a 3^rd party watcher to connect the device with a previous visit as long as a new MAC address is determined for the next association and its encoding algorithm is well-designed; pre-association recognition use cases are supported, additionally the encoding algorithm for the provided MAC address could allow other APs to decode the MAC/ID and recognize the device.
Con ? the device is dependent upon the RCM algorithm being sufficiently random, further, the encoded MAC address, sent in the clear, is now a conspicuous target because it is known to encode information relating to the device.

Option 2 seems to provide the best balance of privacy protection while still accomplishing the goal of restoring functionality eroded by the spread of RCM in client devices.

I am not sure if option 2 would be considered an opaque ID or not, but I don’t think that’s the right question. The question should be:

what is the simplest solution we can add to restore as much of the previous functionality as possible while damaging the RCM privacy improvements the least?

Regards,

Carol

From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Date: Wednesday, September 7, 2022 at 5:45 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

Dear all,

I would like to come back to this issue since there are multiple comments to the bh draft relaying on its re-solution. Summarizing the discussion (forgive me if I may get something wrong):

- The ID may have some meaning and may be used in the authentication and for more purposes

- The ID itself may be something not opaque but always when transmitted it needs to become opaque in order to protect it when used outside an authentication exchange.

I can think of two ways forward:

First option:

May we think of two differentiated terms? maybe Persistent Identifier (PI) when not opaque and Persistent Opaque Identifier (POI) when opaque?

Then in the spec we need to carefully state when we use one and when the other.

(I think this is my preferred choice since it will make everything clearer)

Second option:

Inside 11bh we always talk about the opaque version, but we acknowledge somewhere that the ID itself, when not opaque, may have some meaning.

Thoughts? I think it is relevant to close this discussion during next week's meetings.

Thanks

Antonio

El vie, 19 ago 2022 a las 18:17, Harkins, Dan (<daniel.harkins@xxxxxxx>) escribió:

Jay,

Again, if this new identifier that 11bh is working on is only going to be used in frames used in a post-authentication handshake then there is no point in this group at all!

So maybe the motion should be to disband the group.

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/18/22, 7:02 PM, "Yang, Zhijie (NSB - CN/Shanghai)" <zhijie.yang@xxxxxxxxxxxxxxx> wrote:

Hi Dan,

The device ID keeping the same or difference each time relies on the whether 11bh group agree that it can be carried in authentication frame.

E.g. if 11bh group agree the agreement in 11bi group that device ID/encrypted SAE password identifier is carried in the authentication frame, the device ID shall be different each time as your proposed in annex part. Otherwise, it’s really unnecessary to constraint to usage of identifier as it’s always be protected by the encrypted frame.

I wonder do we need a separate SP/motion to reach the unanimously consent on this? (I’m not sure whether we need to vote the passed motion of 11bi group in 11bh group again although it looks strange).

Thanks

Best Regards

Jay Yang

From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: 2022年8月18日 3:40
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

Well the idea is that the identifiers could be used for other things outside of the protection of the 4way handshake (or equivalent handshake). That being the case they cannot rely solely on the protection of that exchange for their opacity and non-trackability. If these identifiers were only ever going to be transmitted in a KDE and as part of a security handshake then I kind of question the point of this group. Part of the stuff that happens prior to doing the 4way handshake involves authentication and that is supposed to identify the entity and if we already identified the entity we don't need another identifier. If there is one single shared credential for everyone and authentication is "I'm a member of the group that knows the common and shared password" then the motivation for this whole group is like that old joke where the patient says, "Doctor, it hurts when I do this" and the doctor says, "well don't do that."

Regarding whether the AP provides a new random set of bits each time, check out Z.4.

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/17/22, 9:46 AM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

Thanks Dan,

I think (I know) I am not completely understanding, so please forgive me. A couple of questions if I may:

If Opaque used (Annex Z), the STA receives a ‘random set of bits” as the ID first time association and then returns that set as the ID when it returns. Does the AP then provide a new random set of bits (each time) or does the STA keep using the same set of bits?

If Opaque is not used (or even if it is), the ID is still encrypted by the KDE when sent back to the AP, so it will look different to an observer?

I obviously am missing something. My previous comments were solely based on my ‘understanding’ that the ID could be generated either directly or by using Annex Z and hence we need two references. But I admit, I did not understand completely the concept behind Annex Z Opaque ID.

Thanks

Graham

From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Wednesday, August 17, 2022 12:02 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

Hi Graham,

You're right that the device ID needs to be useful but it also needs to be untrackable by a 3^rd 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>
Sent: Tuesday, August 16, 2022 5:12 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

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>
Sent: Tuesday, August 16, 2022 2:09 PM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

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>
Sent: Tuesday, August 16, 2022 1:02 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

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>
Sent: Tuesday, August 16, 2022 10:57 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

-          “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>
Sent: Tuesday, August 16, 2022 11:59 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Any further discussion on proposed resolution to CIDs 12, 58, and perhaps 25

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

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

Antonio de la Oliva
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749

Please consider submitting to:

- Elsevier Computer Communications. Special issue on Digital Twins for the Computer-Networks Evolution (https://tinyurl.com/mr3v9s9d)

- IEEE IoT Magazine Special issue on 6G Mission-Critical Internet of Thing: Services and Enabling Technologies

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