Re: [STDS-802-11-TGBH] TGbh options, considerations, way forward

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

Hi Mark,

Thanks for your feedback.

Regarding Q1, I agree that we should be more specific to move forward. Within this context, according to the SP in November, we have to believe that the group already made a decision to cover ‘pre-association identification’, therefore, we can skipping discussing again whether to cover pre-association identification or not. At this point, it would be better to focus on which solution to choose/modify.

Thanks!

BR,

Okan

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: 2023年1月14日 22:52
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh options, considerations, way forward

Hi, Okan. Thanks for the feedback! Some comments:

I am happy to add further discussion on pre-association identification. However, I’d like to have specific topics we are to discuss. As you note, we’ve had a lot of discussion on this topic, in general, and that includes a straw poll in November on whether the group supports working on a pre-association mechanism in general (17Y, 4N, 3A). So, at this point, to move the group toward a way forward, I think we need to be more specific in what topics/questions we need to discuss. My intention in the questions I have suggested was to get that more specific direction. As I said, I am happy to add further questions/discussion areas, but could you be more specific about what you would like to ask the group?
Agreed, I’ll add e-RRCM. My apologies, I had meant that to be included in the RRCM point itself, but I can see that perhaps there is a different amount of interest in RRCM without/e-RRCM, versus e-RRCM included. I’ll add it.
I have lost track of the request for a joint meeting with TGbi ? thanks for the reminder. I’ll work with Carol, and see what we can arrange.

Mark

From: Okan Mutgan (NSB) <okan.mutgan@xxxxxxxxxxxxxxx>
Sent: Saturday, January 14, 2023 2:34 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh options, considerations, way forward

Hi Mark,

Thanks for the detailed thoughts. If I may share my opinion:

In addition to those “Questions for the group”, I believe that the group should also discuss “pre-association identification” (even though this topic is discussed over and over again, it is still not super clear how to proceed with it).

Could you please add e-RRCM solution (1079r8 ? option 2) to the schemes/options to choose from?
(e-RRCM is the extended version of RRCM. In RRCM, both sides -STA and AP- generate the same RMAs. In e-RRCM, STA and AP still use the RRCM idea but they additionally send a special IE attached to some frames for identification and verification purposes)

Device ID (as in the current D0.2, with updates as agreed in comment resolutions)
MAAD
IRM
RRCM
e-RRCM
IRMA
ID Encoding
PASN extension to Device ID
ID Query*

I remember that bh group was planning to do a session together with bi group. Is this going to happen in the upcoming plenary meeting? That kind of session might be helpful for some points you mentioned.

Thanks!

BR,

Okan

From: Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: 2023年1月13日 14:27
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh options, considerations, way forward

Hi Mark,

Could you help put my contribution 61r1 in the agenda?

Note: The topic in 61r1 is similar to 22/2150, it’s better to put 61r1 after 22/2150 if Graham intends to present 22/2150 in the following interim meeting again.

Also, please see my comments inline.

Thanks

Best Regards

Jay Yang

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: 2023年1月13日 6:28
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] TGbh options, considerations, way forward

All,

Based on the discussions on recent TGbh teleconferences, I’m trying to organize the discussion at next week’s meetings (during the interim session). Here are some thoughts I have. I’m looking for feedback:

What I am missing that we should/could discuss, to help us select the way forward?
Do the questions I’m asking sound like the right ones? Would you phrase anything differently?

Questions for the group:

Do we have agreement that the “paparazzi spoof AP” issue is out of scope for us to try to solve?

à<Jay> I think we can converge the “ paparazzi AP” issue. For 11bh group, we only focus on the “paparazzi AP” issue that the returned STA carries the identifier defined by 11bh group. E.g. if the “paparazzi AP” has the chance to steal the identifier defined by 11bh SPEC, we need to address it. Other “paparazzi AP” issue should be out of scope.

Discuss and reach agreement on whether the OWE use case (or any other style of “open” BSS) is appropriate for use to try to solve.

à<Jay> I set up a mail thread in the reflector, but I don’t see any response, I will update the contribution and present it again.

Discuss and reach agreement on whether we want a STA-generated identifier capability.

à<Jay> If extra benefit can be seen based on STA-generated solution, e.g. covering other use case, we can consider.

Do we need to/how much should or can we provide protection of the network from a “spoof client” attacking it by using someone else’s identification?
- This might depend on whether the network is providing anything based on client identification, like access or other actions. What “other actions” are there that need to be protected from this attack vector? Are there use case scenarios where we don’t care about such protection (MAC addresses were not particularly “secure” before), and should we support this scenario?
Ignoring other considerations, does the group prefer the client’s identification to be carried/encoded in the MAC address, or an IE?

à<Jay>Let’s vote the direction when I present 61r1

General options for way forward (probably start with Pros/Cons for each, then try to down-select):

“Add nothing”: continue with the current 802.11aq capabilities (maybe enhance or clarify these a little bit?), using the MAC Address as the client identifier.

à<Jay> I’m curious what’s the meaning of “Add nothing”? Do it mean we don’t address any use case and disband this group soon?

Make a “small extension” to 802.11aq, similar to MAAD, which allows the address/identifier to change on the same ESS
Go further, to make sure copying and re-using the identification is (reasonably) impossible.
Further yet, completely hide the identification from third-parties with encryption or other obfuscation.

à<Jay> From high level view, we hope the 11bh feature could be adopted by the Wi-Fi industry soon to address current pain point. If the STA vendors hesitate to do it due to kinds of security issue, e.g. new security issue involved. IMHO, 11bh feature will become useless. Obviously, it’s not this group’s target.

I think these are schemes/options we have to choose from:

“Do nothing”/802.11aq or slight enhancements
Device ID (as in the current D0.2, with updates as agreed in comment resolutions)
MAAD
IRM
RRCM
IRMA
ID Encoding
PASN extension to Device ID
ID Query*

(* I’m bringing this back on the list only because someone mentioned during the PASN discussion that only information passed after PASN completes is really protected, so depending on the General option agreement on level of protection and the outcome of the PASN discussion, perhaps we end up back here, after all? If not, we can ignore this scheme.)

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