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

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

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