July 2006 doc IEEE 802 11 06XXXXr 0

July 2006 doc. : IEEE 802. 11 -06/XXXXr 0 Constructing unique key streams for Management Frame Protection Authors: Date: 2006 -03 -6 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 <http: // ieee 802. org/guides/bylaws/sb-bylaws. pdf>, 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 <stuart. kerry@philips. com> 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 <patcom@ieee. org>. Submission 1 Nancy Cam-Winget, Cisco

July 2006 doc. : IEEE 802. 11 -06/XXXXr 0 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! Submission 2 Nancy Cam-Winget, Cisco

July 2006 doc. : IEEE 802. 11 -06/XXXXr 0 Stream Cipher Review Pseudo-random number generator “key stream” byte b Plaintext data byte p 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 b Then: Submission c 2 = p 2 b c 1 c 2 = (p 1 b) (p 2 b) = p 1 p 2 3 Nancy Cam-Winget, Cisco

July 2006 doc. : IEEE 802. 11 -06/XXXXr 0 CCMP Review AES . . . AES padding B 0 B 1 . . . Bk Nonce Construction Header 0 x 59 Priority A 2 PN Dlen (1 b) (6 b) padding Bk+1 0 . . . Submission 0 Same TK with same Priority Payload and PN result in same keystreams for data and management frames C 1 0 x 01 Priority A 2 PN Blki (1 b) (6 b) Br A 1 AES 4 . . . CS mm Am MIC C 0 S m AES A 0 AES Nancy Cam-Winget, Cisco

July 2006 doc. : IEEE 802. 11 -06/XXXXr 0 CCMP Uniqueness • Assign 0 xff 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 0 xffffff 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. Submission 5 Nancy Cam-Winget, Cisco

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

July 2006 doc. : IEEE 802. 11 -06/XXXXr 0 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 0 xffffff and decremented for replay detection; new frame PN value must be less than previous frame • Do we want to address this issue in TGw? Submission 7 Nancy Cam-Winget, Cisco

July 2006 doc. : IEEE 802. 11 -06/XXXXr 0 Motion • Move to instruct editor to add the following text to the TGw draft: “ 8. 3. 3 Construct CCM Nonce Change the first bullet item listed in Clause 8. 3. 3 as follows: - For data frames (MPDUs), the Priority Octet field shall be set to the fixed value 0 (0 x 00) 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 0 xff. ” Submission 8 Nancy Cam-Winget, Cisco