Hi Mark,
On 8/2/23, 9:53 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:
A couple of counter arguments (I think, if I’m understanding the points made):
-
I am concerned that with no minimum length requirement for a Device ID, we will get comments that there is a “security hole” in that an attacker could easily brute force try a lot/every possible short Device ID string until one works.
We’ve had discussions in the past that we don’t want to introduce a mechanism that allows trivial spoofing of a “known” device, by either a rogue STA or AP. As long as we have agreement that we don’t care about this problem, and/or it is out of our scope
to worry about perhaps (in which case maybe we at least want a NOTE?), then I can see arguments for allowing (or at least not disallowing) very short Device IDs.
Keeping in mind why 11bh got formed. This device ID is replacing a plaintext MAC address that was used by networks for identification purposes. I fail to see how a short device ID would open some "security hole" that didn't exist with a
spoofable identifier that was passed in the clear! We didn't get formed because the outcry was "the identifier we were using could be spoofed and we demand more security", it was "the identifier we were using is useless now and we just need something, anything".
I wonder what "until one works" means anyway. Don't we have some status bit saying, "didn't recognize that but here's a new one for you"? So if fear of this "security hole" was real then we should not be expressing a status bit to tell
the attacker that it "works" or not—"you can end your brute force attack now mr attacker, I recognize that value."
Also, maybe this is another reason to use the (optional for now) technique in the Annex. It is computationally infeasible for an adversary to forge a blob even if it knew the size and make-up of the device ID. In addition. It adds padding
to the device ID to make traffic analysis more difficult and adds a tweak to the computation to ensure that blobs will not be repeated. If we are concerned about the security of using device IDs then maybe we should promote the informative annex into normative
text. (And I will take the outcry to not do that as evidence that this security concern is not serious).
I think a minimum length of the device ID (128 bits?) is more the illusion of security. AES-SIV has provable security and we can point to that instead of handwave about how hard it would be to brute force device IDs and what it means to
say "until one works".
-
Ben’s takeaway (just below) seems to have been that the Device ID comes from a “higher layer protocol”. That has not been my assumption. I could imagine that this is possible, but I can also imagine that it is generate (in an implementation-dependent
manner) within the 802 layer. Do we need to get agreement/add clarification on this (again, maybe just a NOTE)?
I guess it depends on the purpose. But regardless of whether it comes from a higher layer protocol or not, the construction of the device ID is outside the scope of 11bh and therefore the resulting length of the constructed device ID is
as well. Let's not constrain the use of this amendment with unnecessary limits on its use.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
Mark
From: Benjamin Rolfe <ben@xxxxxxxxxxxxxx>
Sent: Wednesday, August 2, 2023 8:49 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Minimum length (and optionality) of Device ID
Thanks Dan, that explanation is very helpful.
An alternative to rejecting the comment would be "revised" and clarify the field definition consistent with Dan's explanation. As is it says that it contains something
that is undefined (refers only to an informative annex) which a voter might suggest makes the spec not technically complete.
A change such as:
The Device ID field is an octet string and is defined by the higher layer protocol. See also Annex AD.1.
(borrowing language from 802.11-2020 for similar situations where the content is defined at the network layer).
FWIW it would seem from the discussion that clarification will help. It helped me!
Ben
From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Tuesday, August 1, 2023 5:50 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBH] Minimum length (and optionality) of Device ID
Hello,
I missed the TGbh call this morning but I understand there was a discussion about min/max device ID lengths. It is my opinion that the contents of a device ID and its subsequent length are entirely outside the
scope of the standard. The only requirement is it has to fit in an IE and if you do the Annex encryption stuff you will need to take into account the overhead it imposes (17 octets plus tweak plus padding if used) and make sure your device IDs will still fit
after being encrypted. There is no need to specify a min. STAs don't care what their device ID is (remember, these use cases are entirely to help the network side of the conversation) and the network owns the device ID space so it can do anything it wants.
I would support rejection of the comments that ask for min/max limits on device IDs.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 8/1/23, 9:18 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:
All,
I just wanted to point out a couple examples from the baseline (REVme, that is), for fields which are not always present, and/or have variable length or some restrictions on their length (when they are present).
Supported Operating Classes element:
Note the “(optional)” inside the field’s box, and the “variable” below the box. Also, note that the text then describes when the field is present or not, and minimal information about what it carries when it
is present:
Time Advertisement element:
Again “(optional)” inside the box, and this time a fixed choice of length below the box (0 or a fixed length). And, again, minimal description in the text about when the field is present, and what it means when
it is present:
Multi-band element:
Of interest here, is the use of “4 x m” for the length of the last field. So, there are examples of a simple “formula” type of length, even with an optional field – which can presumably be 0 if m is 0.
QMF Policy frame:
This is one with the possibility of “not present” (0 length), or a specific range of lengths allowed when it is present. And, here the text describes when it is present, and points elsewhere (although still in
clause 9 ?! 😊) for its structure and definition when it is present:
Personally, I think that last example might be the most relevant one for us to mirror, if we decide the Device ID length can be a range (when present), or ours could be like Time Advertisement element if we decide
the Device ID is fixed length (when present).
Other thoughts/flames?
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
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
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