1. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 1 Constructing unique key streams for Management Frame Protection Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date:2006-03-6 Authors:

2. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 2 Overview Current TGw draft 0.02 enables use of TK for protecting unicast data and management frames. Both TKIP and CCMP use a stream cipher construction to provide confidentiality → key streams must be unique!

3. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 3 Stream Cipher Review Pseudo-random number generator Plaintext data byte p “key stream” byte b  Ciphertext data byte c = p  b Decryption works the same way: p = c  b What happens when p 1 and p 2 are encrypted under the same “key stream” byte b? c 1 = p 1  bc 2 = p 2  b Then: c 1  c 2 = (p 1  b)  (p 2  b) = p 1  p 2

4. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 4 CCMP Review SmSm BrBr AES... B1B1 BkBk Header Payload MIC A1A1 AmAm A0A0... 0 padding 0 B k+1... C0C0 SmSm CmCm C1C1 B0B0 AES 0x59 (1b) Priority (1b) A2 (6b) PN (6b) Dlen (6b) 0x01 (1b) Priority (1b) A2 (6b) PN (6b) Blk i (6b) Same TK with same Priority and PN result in same keystreams for data and management frames Nonce Construction

5. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 5 CCMP Uniqueness Assign 0xff as the Priority field in Nonce construction –Ensures unique Nonce construction for management frames What about adapting the PN for management frames? –How does both transmitter and receiver guarantee that counters are unique? –New PN construction can help reduce potential for PN collisions, but is not a eradicate the problem PN is initialized to 0xffffffffffff and decremented for replay detection; new frame PN value must be less than previous frame –A single transmitter PN for both management and data may be prescribed, but can not be enforced ← there’s no means for the receiver to gain guarantees that the counters are unique; single transmitter may restrict architectures to physically bind management and data plane in the same crypto process and force to a single receive counter too.

6. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 6 TKIP Review Ciphertext XOR Plaintext Mixer TK PN Key Stream WEP Packet Key TA Phase 1 Key Mixer 4 msb 2 lsb Same TK with same PN result in same keystreams for data and management frames

7. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 7 TKIP Uniqueness Issue is there even for data streams! Unless TKIP construction can be modified, only opportunity to reduce probability of key stream reuse is to affect a different PN set of rules: –Let PN be a decreasing counter –PN is initialized to 0xffffffffffff and decremented for replay detection; new frame PN value must be less than previous frame Do we want to address this issue in TGw?

8. doc.: IEEE 802.11-06/XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 8 Motion Move to instruct editor to add the following text to the TGw draft: “ 8.3.3.3.3 Construct CCM Nonce Change the first bullet item listed in Clause 8.3.3.3.3 as follows: - For data frames (MPDUs), the Priority Octet field shall be set to the fixed value 0 (0x00) when there is no QC field present in the MPDU header. When the QC field is present, bits 0 to 3 of the Priority Octet field shall be set to the value of the QC TID (bits 0 to 3 of the QC field). Bits 4 to 7 of the Priority Octet field are reserved and shall be set to 0. For management frames (MMPDUs), the Priority Octet field shall be set to the fixed value 0xff.”