1. Motions to Address Some Letter Ballot 52 Comments
January 2003
Motions to Address Some Letter Ballot 52 Comments
Jesse Walker
Intel Corporation
Jesse Walker, Intel Corporation

2. January 2003
Pre-shared keys
There is no informative note indicating that implementations may support more than one pre-shared key
There is no informative note that using the same pre-shared key with more than two STAs, this voids all security guarantees.
Motion: Add informative notes indicating the limitations of the pre-shared key:
“Informative Note: Implementations may support different pre-shared keys for each pair of communicating STAs.
Informative Note: Configurations that share credentials, such as the PSK, may offer acceptable security in some deployments. However, using the same credential among more than two directly communicating STAs may allow any member with that credential to launch replay and forgery attacks.”
Jesse Walker, Intel Corporation

3. Replay Rules and Broadcast/Multicast
January 2003
Replay Rules and Broadcast/Multicast
Clauses (TKIP) and (CCMP) both require that misordered packets are dropped as replays
This does NOT make sense, because any member of the group can create an out-of-order packet.
Motion: In add text
“For all MPDUs a receiver shall increment the value of dot11RSNStatsTKIPReplays for this key”
and in add text
“For all MPDUs a receiver shall increment the value of dot11RSNStatsCCMPReplays for this key”
and add a MIB variable
“dot11RSNStatsTKIPReplays OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
DESCRIPTION: "Counts the number of TKIP replay errors detected."
::= {dot11RSNStatsEntry 15}”
Jesse Walker, Intel Corporation

4. TKIP Counter-Measures
January 2003
TKIP Counter-Measures
Clause has language to “drop any received data messages except IEEE 802.1X messages until the pairwise key is deleted or changed.” Which pairwise key?
Motion: Replace the phrase “pairwise key” with “PTK” in clause
Jesse Walker, Intel Corporation

5. January 2003
Key Deletion
Clause has text requiring “keys” to be deleted. It does not identify which keys these are.
Motion: In clause replace “pairwise key” by “PTK”.
Jesse Walker, Intel Corporation

6. PRF Pseudo-code/Reference code Mismatch
January 2003
PRF Pseudo-code/Reference code Mismatch
The reference implementation for the PRF does not match that in pseudo-code
The pseudo-code is correct but the reference implementation is not
Motion: Replace the reference source code and test vectors with the HMAC-SHA1 based PRF from doc 2-795
Jesse Walker, Intel Corporation

7. January 2003
PRF Language Error
The text describing the PRF contains two errors that are incompatible with usage and with the pseudo-code:
It says that the length is represented as a byte, but the remainder of the draft allows lengths larger than 255 (cf., PRF-384, PRF-512)
It says the counter value is 0, rather than just initialized to 0
Motion: Replace the PRF text with the HMAC-SHA1 based PRF text (Clauses “PRF Interface”, “Notation”, and “PRF-SHA”) from doc 2-795
Jesse Walker, Intel Corporation

8. PRF and Key Entropy HMAC internally hashes its key parameter
January 2003
PRF and Key Entropy
HMAC internally hashes its key parameter
When SHA1 is the hash, this implies that the derived PTK has at most 160 bits of entropy
We cannot get the full benefit of the full PMK
Motion: Insert into the Draft the text for the AES-based PRF (Clause “PRF-AES”) defined in doc and make its use mandatory for CCMP and WRAP.
Jesse Walker, Intel Corporation

9. January 2003
PRF Label Collisions
includes the text “…while CCMP, WRAP, and WEP use X =384…”
Since all three use the same X value and the same label, this means that the security of the PRF depends on other parts of the design guaranteeing that the nonces are distinct for every invocation of the PRF.
Motion: Adopt the text from doc (Clause “PRF Usage”) that addresses this problem.
Jesse Walker, Intel Corporation

10. January 2003
GTK Generation
The existing GMK hierarchy is a relic from the days before we agreed that every device must implement a genuine random number generator
Any properly generated GTK will be indistinugishable from random.
The Group Key hierarchy is not testable
Motion: Add text to
“The Authenticator shall produce GTKs by a technique that guarantees that each GTK is indistinguishable from random.”
and change the existing method for generating the GTK from mandatory to an informative example. Change the name of clause to “Group Temporal Key”.
Jesse Walker, Intel Corporation

11. January 2003
EAPoL RC4 Key Wrap
Even though we discard the 1st 256 bytes of key stream from RC4, we still use an IV with the KEK to wrap the GTK for an RC4-based protocol.
Motion: Do not use the IV for wrapping the GTK. Instead, in clause specify the following algorithm for the RC4 key wrap: “To wrap the GTK for an RC4-based protocol, if l is the wrapped key length in octets, wrap the k-th key using bytes 256+(k–1)l, 256+(k–1)l+1, 256+(k–1)l+2, …, 256+(k–1)l +l–1 of the RC4 key stream generated under the KEK, for k = 1, 2, 3... Key stream byte 256+(k–1)l +j, is used to RC4 encrypt byte j of the kth GTK, for j = 0, 1, …, l–1. Here the EAPoL-Key Replay Counter k is the value used in the EAPoL-Key descriptor transporting the key.”
Jesse Walker, Intel Corporation

12. Difficulty Distinguishing 4-way Handshake Messages
January 2003
Difficulty Distinguishing 4-way Handshake Messages
Only required difference between some 4-way handshake messages are some of the flags fields.
This makes for very fragile implementations that might be subject to reflection attacks.
Motion: In clause 8.5.2, rename the IV field the XID field. Replace the IV field text with the following: “For the 1st message of the 4-way handshake and for Group key handshake messages this field shall be 0 on receive and ignored on receive. For 4-way handshake message n, n  1, its value shall be octets 0-15 of the SHA1 hash of 4-way handshake message n–1.”
Jesse Walker, Intel Corporation

13. EAPoL Replay Counter Problems
January 2003
EAPoL Replay Counter Problems
As specified, both Authenticator and Supplicant specify the Replay Counter value from the same space.
Motion: In clause replace the description of the the Replay Counter with “The Replay Counter is always set to 0 by the transmitter and ignored by the receiver for the 4-way handshake. The Supplicant and Authenticator shall maintain separate replay counter values for EAPoL Requests and Group Key Handshake.”
Jesse Walker, Intel Corporation