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

Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)



As Jaarko correctly pointed out, the STA has no idea if the Device ID is opaque or not.  Hence the description needs to be changed to make sure this clear.

 

How about:

“If the AP is allocating an identification that has external meaning (a username, account number, etc) it 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 device identification is private (opaque) from third parties. The AP can use the informative procedure in Annex Z, which affords the required security and privacy, to protect the device identification within a Device ID.”

 

The question still remains, again to Jaarko’s point, as to why or when a STA might transmit the Device ID in an unencrypted frame?  If the only foreseen use is PASN, then maybe we just specify it for PASN with Device ID? 

 

Graham

 

 

From: G Smith
Sent: Thursday, April 13, 2023 11:39 AM
To: Jarkko Kneckt <jkneckt@xxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)

 

Hi Jaarko,

Yes you are right, the STA has no control over this at all, and maybe that is what is missing.  As I understand it, the STA simply sends the “Device ID” it gets and does not know if it is opaque or not.  This would mean that the AP has to know in advance if the STA will send it in an unencrypted frame (when might that happen?).

 

Maybe we need a lot more words to explain this clearly.

 

Thanks

Graham

 

From: Jarkko Kneckt <jkneckt@xxxxxxxxx>
Sent: Thursday, April 13, 2023 10:57 AM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)

 

Hi Graham, all,

 

I cannot agree to send Device ID in a non-protected frame or at least provide encryption to the Device ID. 

Currently AP is fully in control of Device ID. STA cannot do anything to the Device ID, just transmit the same ID as assigned by AP.

I think no STA will send Device ID clear OTA.  

 

Cheers,

              Jarkko 

 

 

 

On Apr 13, 2023, at 7:23 AM, G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

 

Hi Mark, et al,

Can we first agree also on the opening text that Mark suggested?  I think it clearly states that only if the Device ID is sent in an unencrypted frame is “opaqueness” required.  

 

“When it is desirable to use a device identification which is relatively permanent, for example an identification that has external meaning (a username, account number, etc.), and the Device ID carrying the device  identification might be communicated without encryption, it is necessary that the Device ID keep the device identification private (“opaque”) from third-parties.” 

 

Then we are looking only at the final “Annex Z” sentence?

 

May I also make another suggestion (small edits to Mark’s words) for the last sentence?

 

“In such cases, the informative procedure in Annex Z, which affords the required security and privacy, can be used to protect the device identification within a Device ID.”

 

 

Graham

 

 

 

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx> 
Sent: Wednesday, April 12, 2023 7:03 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)

 

Thanks, Ben.  Good point/catch.

 

(We also need to rename this clause, since it definitely won’t be Annex Z, also, but will be Annex A<something>.)

 

Mark

 

From: Benjamin Rolfe <ben@xxxxxxxxxxxxxx> 
Sent: Wednesday, April 12, 2023 4:27 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)

 

To be a stickler for technical correctness,  "Annex Z may be used" would be correct only if Annex Z is normative.  If Annex Z is informative, the correct word is "can".

Such might raw a comment during balloting from someone who searches for correct use of normative langauge.  

FWIW

Ben


From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, April 12, 2023 1:50 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)

 

All,

 

  • Graham’s suggestion to just say " Annex Z may be used" (drop the "or another procedure" language)
  • Dan lists the requirements from the first paragraph of Annex Z, that would be the "comparable security and privacy" criteria
  • Amelia lists a set of requirements pulled from 802E

Can we find consensus on a direction between these?  (And, we need specific text for this paragraph in our amendment once we have an agreed direction, by the way).

 

@Yang, Zhijie (NSB - CN/Shanghai): We can’t seem to reach consensus on any proposed text (mine, or others).  So, please suggest some alternative if you think I went too far.  I’m just trying to satisfy comments I’ve heard on the call(s), and find something that would be acceptable.  Note that we are not restricted by process to the comment’s specific scope, to reach a resolution.  We are only restricted by what the TG finds as a consensus to proceed.

 

@Jarkko Kneckt: Can you clarify if (your words) “the Device ID should be transmitted only in encrypted frame” would include the Device ID being encrypted within an Annex-Z-produced structure (or similar) in an unencrypted frame, or did you really mean that the _frame_ must be encrypted?  (Note, by the way, even some 4-way handshake/FILS authentication/PASN frames are not literally encrypted frames, but are frames with encrypted components.)

 

And, re-iterating Dan’s comment, please note that we need proposals (actual text to put in the amendment), and please not just reasons for objecting to proposed text without providing your preferred alternative.

 

Thanks.  Mark

 

-----Original Message-----
From: Amelia Andersdotter <amelia.ieee@xxxxxxxxxxxxxxx> 
Sent: Wednesday, April 12, 2023 1:37 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda uploaded - plans for call)

 

Hi Jay,

 

As the commenter I would not be against making it more explicit that an alternative procedure (or proprietary procedure!) needs to afford a comparable level of security and privacy.

 

The level of security and privacy would be compared to the procedure in Annex Z. If we wanted to be more specific about comparisons on privacy, I believe 802E Privacy Recommendations Clause 8 has a checklist with many complications that arise when dealing with identifiers. The device ID or opaque identifier (or private identifier) could conceivably be evaluated against these criteria:

 

1. Temporary identifiers should be used or at least permitted, especially for the use of short-lived services such as network probes.

2. Temporary identifiers should not persist across different stages of the communication process and should be restricted to specific protocol exchanges.

3. When switching to a new temporary identifier, variable fields such as sequence numbers should be reset to their default value or to a non-deterministic value. Where multiple temporary identifiers are used concurrently, their replacement should be synchronized to avoid correlation between sets of old  and new identifiers.

4. A personal device persistent or temporary identifier should not be stored by any device specified by the standard other than the devices using those identifiers to provide or support the service.

5. Persistent and temporary identifiers should not be stored by any device for longer than is required to rovide or support the service.

6. Periodic communications or transmissions of deterministic values or identifiers should occur at non-correlatable intervals.

7. Temporary identifiers should not be shared across services.

8. The use, persistence, and storage of identifiers by devices specified in the standard, and their configurability, should be described in the standard.

 

Best regards,

 

Amelia

 

 

On 2023-04-12 03:48, Zhijie Yang (NSB) wrote:

> Hi Graham,

> Yes, I already made the comments on “what is the comparable security

> and privacy”? during the call yesterday. The proposed text force the

> AP vendor must find a solution like Annex Z did. I’m not sure how

> other AP vendor think it about.

> Further, we don’t have any consensus on the device ID carried in the

> unencrypted frame. I think we need a SP on this part before we talk

> the resolution.

> Hi Mark,

> I hope we could focus on the comment itself and move forward, the

> commenter says:

> “I guess I'm in general a bit confused as to whether "the identifier"

> is always an "opaque identifier" as in Annex Z, or whether there are

> different identifiers defined in subclause 12.2.11. Adding a sentence

> on identifiers would help, perhaps along the lines of "An opaque

> identifier can be constructed by the network according to the example

> procedure in Annex Z, but an identifier can also be differently

> constructed by a mechanism chosen by the network." I guess the non-AP

> STA would not technically need to be concerned with how the identifier

> is constructed.”

> The proposed resolution should be like “An device ID can be

> constructed by the network according to the example procedure in Annex

> Z, but it can also be differently constructed by a mechanism chosen by

> the network, the device ID should be opaque over the air”

> But your proposed resolution is beyond what the commenter’s comment.

> If someone have other intention on this, we could address it in the

> next round on a dedicated CIDs.

> Thanks

> Best Regards

> Jay Yang

> *From:* G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>

> *Sent:* 2023412 5:05

> *Subject:* Re: [STDS-802-11-TGBH] TGbh language for Annex Z (WAS:

> Agenda uploaded - plans for call)

> Hi Mark,

> I think you are close.

> As we have not had any other proposals for an “opaque” ID scheme, and

> I think we may get comments on “what is the comparable security and

> privacy?”;  maybe we make it a little stronger in Annex Z’s favor?

> How about changing last sentence to simply read:

> “In such cases, the procedure in Annex Z may be used to protect the

> device identification within a Device ID.”

> I am sure you will get other ideas, but thought I might kick it off.

> Graham

> *From:* Mark Hamilton <mark.hamilton2152@xxxxxxxxx>

> *Sent:* Tuesday, April 11, 2023 2:13 PM

> *Subject:* [STDS-802-11-TGBH] TGbh language for Annex Z (WAS: Agenda

> uploaded - plans for call)

> All,

> At risk of stepping into the fire again, here is another suggested

> approach to our language introducing the Annex Z procedure.  My intent

> is to provide enough context to explain why this is used/useful.

>   * Insert a new paragraph at the end of 12.2.11.1 (subclause

>     numbering per 11-23/0129r4): “When it is desirable to use a device

>     identification which is relatively permanent, for example an

>     identification that has external meaning (a username, account

>     number, etc.), and the Device ID carrying the device

>     identification might be communicated without encryption, it is

>     necessary that the Device ID keep the device identification

>     private (“opaque”) from third-parties.  In such cases, the

>     procedure in Annex Z, or any procedure that affords comparable

>     security and privacy, can optionally be used to protect the device

>     identification within a Device ID.”

> Comments?

> Mark

> *From:* Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>

> *Sent:* Monday, April 10, 2023 11:38 PM

> *Subject:* Re: [STDS-802-11-TGBH] Agenda uploaded - plans for call

> Hi Dan,

> Thanks for the comments.

> I quickly check the gramma, I see “opaque” can be adj., verb or noun.

> 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 3^rd party?

> Thanks

> Best Regards

> Jay Yang

> *From:* Harkins, Dan <daniel.harkins@xxxxxxx>

> *Sent:* 2023411 12:35

> *To:* Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>;

> *Subject:* Re: [STDS-802-11-TGBH] Agenda uploaded - plans for call

>   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 3^rd party.

> Thanks

> Best Regards

> Jay Yang

> *From:* Mark Hamilton <mark.hamilton2152@xxxxxxxxx>

> *Sent:* 2023411 6:55

> *Subject:* [STDS-802-11-TGBH] Agenda uploaded - plans for call

> 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

> <mailto:daniel.harkins@xxxxxxx> and @Amelia Anna Matilda Katarina

> Andersdotter <mailto:amelia.ieee@xxxxxxxxxxxxxxx>, 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

> g_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwMFaQ&c=eu

> GZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOir

> z2RA_bah_KFKOseb8&m=ljoUTvDs00q41Rd0a7MvJC_zqgc8hF9b22GsKPZysMs&s=HK__

> 8xeBWujj6bQ0D1xBDGK9dGhmyjxHeD1LhAxxLtE&e=>

> ----------------------------------------------------------------------

> --

> To unsubscribe from the STDS-802-11-TGBH list, click the following

> g_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwMFaQ&c=eu

> GZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOir

> z2RA_bah_KFKOseb8&m=ljoUTvDs00q41Rd0a7MvJC_zqgc8hF9b22GsKPZysMs&s=HK__

> 8xeBWujj6bQ0D1xBDGK9dGhmyjxHeD1LhAxxLtE&e=>

> ----------------------------------------------------------------------

> --

> To unsubscribe from the STDS-802-11-TGBH list, click the following

> g_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwMFaQ&c=eu

> GZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOir

> z2RA_bah_KFKOseb8&m=ljoUTvDs00q41Rd0a7MvJC_zqgc8hF9b22GsKPZysMs&s=HK__

> 8xeBWujj6bQ0D1xBDGK9dGhmyjxHeD1LhAxxLtE&e=>

> ----------------------------------------------------------------------

> --

> To unsubscribe from the STDS-802-11-TGBH list, click the following

> ----------------------------------------------------------------------

> --

> To unsubscribe from the STDS-802-11-TGBH list, click the following

> ----------------------------------------------------------------------

> --

> To unsubscribe from the STDS-802-11-TGBH list, click the following

 

-- 

^\...~...~...~...~...~.../^

Amelia Andersdotter

^\...~...~...~...~...~.../^

 

________________________________________________________________________

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

 


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