| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Dan, Please note that latest version of P802.11az draft is D0.6 available on mentor (and not 0.5). I also CC the TGaz editor as some of your comments below are editorial ones. Best, Jonathan Hello, I read draft 0.5 and found it somewhat confusing. There seems to be a few things going on
security-wise but I couldn't piece it all together. Therefore some of these questions may just be misunderstandings but if I'm confused then there's a good chance other people are too so it might be a good idea to clarify things considerably. Anyway, here are my comments: 1. Is SAC "sequence authentication code" (page 3, line 3) or "secure authentication code"
page 20, line 25? 2. page 20, line 25, where is figure 9-51f? 3. page 20, line 32 says the secure variant is described in 11.22.6.4, but it doesn't seem to be. 3. Few from Section 9.4.2.166: 3a: Figure 9-aac (32.16) is ranging operations parameters field which is part of the EDMGz specific parameters subelement which is included in a Fine Timing Measurement Request Frame. So "secret Key" and "salt" are sent in the clear in the initial request frame? Really? 3b: "The Secret Key subfield is used to carry the secret key which is used along with Salt value contained in the Salt subfield, to generate the random sequence(s) as described in Section ???" -- what is ??? (page 33, lines 4-5) 3c: How is this "secret key" generated? 4. page 70, line 30 and line 34 will always generate different "Secure-LTF-bits". Apparently this is because different keys are used by the RSTA and ISTA (??? Is this the case???). Which is fine but then they should be named differently. This is way too confusing. 5. page 70, lines 37-38: what is that Length? SAC is apparently 16 octets, fixed; what is the length of Secure-LTF-bits? For the ISTA Length = length of Secure-LTF-bits. 6. Few from Section 12.2.9: 6a: page 104, line 4: first 32 octets of "the Secret Key" are an encryption key for CCMP. What's the IV or counter used for CCMP? How is it guaranteed to be unique? 6b: page 104, line 24: for example? The Info field must be fixed to ensure interoperability. You can't leave it up to "for example". 6c: page 104, lines 14-32: what's the length of this Secure TRN Sequence? 7. Section 12.2: it is shown how the HLTK is produced by turning the KDF crank some more but what is the input? It's a PMK. Which one? Not the cached PMK for the "Base AKM", right?
8. Few from Section 12.13.3: 8a: PASN authentication does an ephemeral diffie-hellman but it is not clear what is done with that secret. The claim is that this exchange produces a PTKSA according to 12.xx (which is not helpful) but PTKSAs are created as a result of the 4-way handshake (as described in the changes to 12.2) not as the result of an ephemeral key exchange (which usually results in a PMKSA). 8b: page 109, line 1: How does PASN tunnel FILS shared key and SAE protocol data? Is there a reason FILS shared key was chosen over FILS public key? Is it not possible to tunnel FILS public key data? 8c: page 109, line 6: not sure how the "comeback cookie" works. That needs further explanation. 8d: page 109, line 16: How are ECC private keys generated? Without a cryptographic RNG? Hopefully you can address these before you go out to letter ballot. regards, Dan. To unsubscribe from the STDS-802-11-TGAZ list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1 To unsubscribe from the STDS-802-11-TGAZ list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAZ&A=1 |