Re: [STDS-802-11-TGBH] ID encoding
"Who allocated the ID?": I'd expect AP to be one doing that similarly
to what is done in MAAD and there is no need for this to be some
"permanent thing", i.e., it can change on every successful association
to an ESS. In theory, other options would be doable as far as the
encoding mechanism is concerned, but I'd agree this would get to all
the debate about having to define under what rules such values would
be assigned and how they could be unique enough, etc., and as such, it
would be simplest to just use the AP/ESS-assigned approach.
"Does this have any real advantage over MAAD in the TGbh context?":
This depends on what are the pre-association use cases we are trying
to address. Sure, extra complexity is not needed for some cases like
client steering where it does not matter much, if at all, if an
attacker would be able to clone an ID and use it. However, it might
matter if people are really considering of some access control related
items and operations like detecting an owner of a house arriving at
the house and then taking some actions based on that (before an actual
association), say opening some doors/locks or increasing thermostat
level, etc. Similar concerns would apply to parental control like use
cases where a shared passphrase/password is used but the MAC address
alone is used to detect whether the station can use a network or some
services at some time. I do not personally think we should be
addressing such use cases in P802.11bh, but if there is possibility of
those being something that P802.11bh is going to be used for, there
may indeed be need to provide significantly more robust protection
than is possible to do with MAC addressed based schemes. And if we do
include a mechanism that does not provide sufficient protection for
foreseeable use cases, we should clearly describe the constraints of
the mechanism(s) in the draft and warn against its use in cases were
it is not sufficient and could result in security vulnerabilities.
I would also point out that if we are planning on addressing only such
pre-association use cases that do not have any kind of additional
protection needs, I'm not sure we would need even the MAC addressed
based mechanisms like MAAD. Most RCM implementations today use a
random, but not changing, MAC address for each ESS. This should be
sufficient to cover a large portion of the pre-association use cases
in a very similar manner to how the globally unique MAC address was
used. Diagnostics can use this (most STA UIs today seem to provide
easy access to that persistent per-ESS random MAC address) and so can
client steering (with potentially guidance to non-AP STA to consider
using the same address for active probing when targeting a connection
to a specific ESS). Similar consideration could be done for the
waking-up-sleeping-APs use case that MarkH mentioned in Bangkok. And
also for some presence detection things if they do not concerns about
cloning attacks. Are these cases really broken if the STA is using a
persistent per-ESS random MAC address?
Regarding IRMA, if I understood it correctly, it is also using the MAC
address field in the header to provide identifiable-to-an-ESS
information with an additional information element providing guidance
to how to interpret the MAC address. One reason for my proposal to
consider options that do not use any rules on the actual MAC address
is to avoid potential non-AP STA implementation concerns by completely
separating TGbh mechanism from the way the STA decides which random
MAC address to use. That can make things quite a bit more convenient
to implement and in some existing devices, will likely allow the
mechanism to be implemented while a specific protocol/rule determined
or AP assigned random MAC address might prevent implementation (in
particular in cases where multiple parallel operations are performed
with different MAC addresses).
- Jouni
On Mon, Nov 21, 2022 at 5:13 PM G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Jouni,
>
> Thanks for your presentation 22/2013r1. have the following comments:
>
>
>
> Unclear who allocates the ID. Does non-AP STA allocate or AP, or both?
>
> If both advertise support and non-A STA does not include ID IE in request, does AP include ID IE in the response?
> Can non-AP STA allocate? If non-AP STA includes a “not recognized” ID IE we are back to the discussions that have plagued Device ID.
>
> Then, how is ID changed? Presumably it needs an ID IE from the AP or does the non-AP STA control?
> If the IE is not encrypted then there is no difference to the MAAD scheme except I can’t see any advantage in adding an IE which acts as an identifier. In fact, this could be construed as a fingerprint for this STA. In MAAD the MAC address appears random even though identifiable by one AP. The mere presence of the ID IE clearly sets the non-AP STA apart.
>
> Non-AP STA could I suppose include a dummy ID each time, as if not, it identifies clearly which APs it is interested in, encrypted or not.
>
> Encrypting the ID means that the STAs need to store the ID and the key for each connection, plus the need to carry out the computations each time , plus noting the timestamp from the beacon, assuming that it can get the request on the air before the next beacon. But, need to ask for what purpose encrypt?
>
> In TGbi I had a lot of push back on the ‘paparazzi attack’ with what appeared to be a general view that protection to this was not needed. If so, then MAAD works fine as is and the idea that somehow an attacker copies the MAC address and then uses it to ‘fool’ an AP is moot. In fact, as I have pointed out numerous times, “so what”, even if this does happen, the bandit can’t associate anyway so why waste time adding computations and complexity?
> So, what “replay frames” or “cloning” problem is the need to encrypt addressing? In practice it is not a problem (can’t associate anyway, and it seems that this attack is not of interest anyhow) and hence does not merit adding computational complexity.
>
>
>
> Will this scheme work – yes
>
> May this be of interest to TGbi - maybe
>
> Does it have any real advantage over MAAD in the TGbh context – No
>
> If this ID IE is only included when addressing an AP to which it wishes to be pre-identified, then it is an obvious giveaway. With MAAD, for example, there is nothing to show that this AP is special.
>
>
>
> Finally I would like to note that TGbh is looking for easy to implement solutions to quickly address the Use Cases broken by RCM. How quick and easy to implement is this scheme compared to MAAD? - for me, MAAD wins easily and is a TGbh solution.
>
>
>
> Thanks
>
> Graham
>
> ________________________________
>
> 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