Hi Mark,
Please put my contribution 22r1 to the agenda, I can present it in the 3rd or 4th session.
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?
- 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.
- Discuss and reach agreement on whether we want a STA-generated identifier capability.
- 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?
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.
- 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.
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