Re: [STDS-802-11-TGBH] ID encoding
Hi Jay,
Thanks for your points. I have to admit that when it comes to the group key/public key stuff I am sure that I do not fully understand. I did not appreciate that the "public key received in the 4-way handshake" is the same for every STA. I do understand the group key is the same - is that the key being used here?
My intention is to make sure I understand the differences between ID encoding and IRMA, and also to make sure that everyone does understand what IRMA actually is (as well as MAAD) and hence make an informed decision.
Also, I suspect that I am not the only one that struggles with the "keys" and the details and nuances of things like HPKE and HKDF etc.
In IRMA I simply needed something to encode a random MAC Address with a key, the result included in the IE. The key is unique for each STA, changes every association, and is effectively the ID for the STA. True, this means that the AP needs to go through its list of keys to find the one that corresponds to the result in the IE, but I added the "Check key" idea to reduce the list by 256. In practice this should be then be a trivial exercise. What hash or key function to use, I am open to suggestions, maybe HPKE would work, I don't know enough about it.
In ID encoding I am unsure of what the AP has to do and what it is identifying. I am assuming that an "ID" is encoded with a key (same key for all STAs?), and entered in the IE. True, if the AP only has one key then the ID is simply decoded, and the AP searches through its list of IDs, but is that what it is? Does the ID change every association? I take your point that one key seems very insecure.
The other question is whether the "Timestamp" is needed. In TGbi, it was ridiculed that the copying attack was real, i.e., a spoof AP is set up for the "home" network. If this is not a real attack, then there is no need to have the time because copying the association request is futile, and, indeed, MAAD is perfect and simple. Think about it, nothing is there to indicate what network the MAAD MAC Address relates to, and the same STA has many MAAD MAC addresses so how does attacker know which network to use it on?
So to me it seems that the ID encoding idea is simple in that it only needs coding and decoding of an ID, using the same key for every STA addressing that AP. If so, I would propose that it is in fact slightly less secure than MAAD( but needs more computations), and certainly less secure than IRMA, but maybe that is OK? Needs a lot more discussion.
Just thoughts
Graham
-----Original Message-----
From: Zhijie Yang (NSB) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Monday, November 28, 2022 10:00 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] ID encoding
Hi Jouni, Graham,
I would like to jump in the discussion as I see Jouni provide a good direction for the identification of pre-association scheme.
As some group members mentioned the ID copy issue many times, we should have a solution to consider that the MAC address is never used as the identifier in pre-association scheme.
The mainly concern on "ID encoding" solution lies in one public key used for all approved STAs. Once the public key is disclosed outside, the whole AP/ESS is not safe anymore. The 3rd party can mimics as an legitimate STA and perform an illegal operation as it wants. On the other side, the ESS/AP doesn't have any chance to update the public key, as the ESS/AP can't predict when the approved STA return to the same ESS. In other word, group key/public key rekey operation only works for the "on-line"(post-associated) STAs, like group key rekey operation in current SPEC. I can image the ESS/AP has to always using the same public key until its power off in the implementation if we work on this approach.
Therefore, it's better to use pairwise key to encrypt the additional IE, like the proposal in "ID encoding", rather than group key.
The old IRMA is a good example to use the pairwise key to encrypt the additional IE, in which there is no negative effect to other STAs when one pairwise key is disclosed outside, because other STA use different pairwise key. But the problem is that the computational cost is too high on AP side as AP has to calculate all HASH values based on current DB to find the right key.
In order to combine the merit of "ID encoding" and old IRMA, I think we can have a solution to use "RMA" as the index to help AP find the pairwise key to decrypt the additional IE, in which both the key disclosed outside concern and AP computational cost concern can be addressed.
Actually, The current 802.11 SPEC has already provided a similar approach, called "PMK ID", in which both side generate the "PMK ID" locally, and it will be used to find the same PMK in next association.
And also, when we talk the topic "who allocates the ID". We can also follow current "PMK ID" scheme, in which both sides generate the identifier based on certain algorithm.
When we talk the use case of "access control" based on certain identifier, the current state is that there is no solution for mobile AP product with very limit resources to allow some special STAs associated at any time. The mobile AP only support 4--8 STAs associated at the same time in some implementation.
Some members recommend the "SAE password identifier" solution, but I don't see any client support such function. On the other hand, "SAE password identifier" solution itself has some trackable issue, and 11bi group proposes to address it. Some members recommend to use "802.1X" solution, I can't image how a mobile AP/cellphone can connect to an authentication server.
That's to say, if we want to have the access control implementation on the mobile AP product, we have to wait for 802.11bi SPEC released. In other word, no solution in IEEE group until 2025...
Thanks
Best Regards
Jay Yang
-----Original Message-----
From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: 2022年11月28日 22:46
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] ID encoding
Hi Jouni,
Thanks for the response.
I think that this proposal is in fact very similar to IRMA. In IRMA the MAC address is always random, it is not an identifier. The difference is that random MAC Address is used to create the Hash (or whatever it may be called) that is formed with the key that is exchanged every association. The key (the IRMK) can be seen as the identifier.
The original criticisms that were levied at IRMA were solely on the computations required, i.e. if the AP was remembering 1000 STAs, too much work to find the one. Hence I added the IRMK Check idea.
I sort of went off the IRMA idea as it seemed that the 'computational requirement' was causing problems to the AP section. Hence I proposed the much simpler MAAD idea.
I am sure we can discuss further.
Thanks
Graham
-----Original Message-----
From: Jouni Malinen <jkmalinen@xxxxxxxxx>
Sent: Monday, November 28, 2022 6:02 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: 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://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org
> _cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwIFaQ&c=euG
> ZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOirz
> 2RA_bah_KFKOseb8&m=rF5maon6TCA_Q8KeWLA5hc06-TOtpck4NOGmmOa0R9g&s=Cdlke
> I8dLeMu4IfeVpfmLCbX6nCdzwJZuNoDHW4Qo20&e=
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOirz2RA_bah_KFKOseb8&m=rF5maon6TCA_Q8KeWLA5hc06-TOtpck4NOGmmOa0R9g&s=CdlkeI8dLeMu4IfeVpfmLCbX6nCdzwJZuNoDHW4Qo20&e=
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D11-2DTGBH-26A-3D1&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Z3s2jA8rgZoSco8f4kvDx_nOirz2RA_bah_KFKOseb8&m=tW7s2YCXCjXpHe2Kzns4NtIoAwycHfafOA9dCamqSsI&s=wBeE8RLZcf5SxHh0IXAoNvs4zMKuRgNLutSorvPwPpc&e=
________________________________________________________________________
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