| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
I think we might've just opened a can of worms…. KDFs are carefully constructed cryptographic tools and we (802.11) should not be redefining what they are or how they're constructed. We should refer to documents describing KDFs built and analyzed by competent cryptographers. So what
do we refer to? Well, NIST SP 800-57 rev 4 but guess what? That's been withdrawn (we should refer to rev 5). And it doesn't really talk about KDFs anyway, SP 800-56b and -56c do though but we don't refer to them (we should, at least -56c). In NIST SP 800-56b and -56c the input keying material is described as a "byte string" which we can call an "octet string" I guess. The length of the output is defined in bits though and just to throw a wrench into the works the "other
info" added to the KDF, which is some context-specific goo, is described as a "bit string". So it's kind of all over the map. So what do we use? Well, looking at 12.7.1.6.2 (KDF) in REVme it says the input keying material is "a key" (no units described, but down below it's called a "bit string", which differs from the NIST SP definitions) "whose length equals
the block size of the hash algorithm"! Now where did that last bit come from? It is certainly possible to pass in input keying material to a hash-based KDF whose length is greater than the digest of the underlying hash function. All our KDFs are HMAC-based
and if you look at HMAC it starts out by checking whether the input keying material is greater than the digest of the hash function being used and if so to hash it down. If we want to use it that way—i.e. don't call the KDF with input keying material that
is larger than the digest of the hash function you're using in the KDF—then we can use it that way but I don't think we should be defining constraints like that in a tool that specifically does not have them.
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 6/27/24, 9:46 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote: --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Ali, Thanks for this contribution. A couple comments:
1)
At the top of page 6 (my pagination, anyway), you suggest defining the function “L()” in 12.1. I believe the intention of REVme is to change the name of this function to “ExtractBits()”, which is (now) defined in subclause 1.5 of REVme
draft. Can I suggest that instead of your direction, that we should just change the use of L() to be use of ExtractBits() throughout clause 12 (or anywhere else) in the 802.11az material?
2)
I disagree that KDF is “meant to” operate on octet strings (again, near the top of page 6 in your document). This can be seen in the existing uses of KDF, for example in 12.4.4 (for SAE hunt-and-peck – maybe we don’t care?), 12.7.1,
12.11, etc. If 802.11az material explicitly uses KDF with an octet-based assumption, then the 802.11az material should be modified, I think. Although, as I review 802.11az, I’m not seeing a problem. Thanks. Mark From: Jon Rosdahl <jrosdahl@xxxxxxxx>
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Resend Email on behalf of Ali to update the Subject line to make it easier to find the topic along with the document number and link to submission. Hi Mike, I have uploaded 11-24/1070r0 (https://mentor.ieee.org/802.11/dcn/24/11-24-1070-00-000m-comment-resolutions-for-secure-ranging.docx)
to address some of the discrepancies within in ‘secure Ranging’ specification of REVme D6.0 in case members want to review before my presentation. Regards, Ali
----------------------------------------------------------------------------- Jon Rosdahl Engineer, Senior Staff Email: jrosdahl@xxxxxxxx A Job is only necessary to eat! To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |