CCMP Nonce Construction September 2006 doc.: IEEE 802.11-06/1444r0 September 2006 CCMP Nonce Construction Date:2006-09-17 Authors: 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:// ieee802.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>. Henry Ptasinski, Broadcom Henry Ptasinski, Broadcom

September 2006 doc.: IEEE 802.11-06/1444r0 September 2006 Overview This submission presents further consideration for how to ensure TGw meets its security goals In Summary: Frames for the purposes of protection and replay detection must ensure unique nonce must ensure replay detection cannot be attacked Henry Ptasinski, Broadcom Henry Ptasinski, Broadcom

802.11i Composition 802.11i is designed to protect data frames September 2006 802.11i Composition 802.11i is designed to protect data frames 802.11w leverages these mechanisms to also protect management frames…but: Data frame replay detection in 802.11 requires that frames within each access (AC) are transmitted in order TGw must consider: Management frame ordering is independent of data frame ordering Henry Ptasinski, Broadcom

Management frame and Data frame ordering are Independent September 2006 Management frame and Data frame ordering are Independent Under EDCA, management frames are sent at AC_V0 without being restricted by admission control procedures Management frames queued after AC_VO data frames will be transmitted first if the data frames are blocked due to admission control Management frames must be treated as a separate stream from data frames For the purposes of protection and replay detection Must ensure unique nonce Must ensure replay detection cannot be attacked Henry Ptasinski, Broadcom

TGn: another consideration September 2006 TGn: another consideration TGn defines Management Action Frame inside a QoS-NULL data frame Considered in TGn as a distinct stream from regular data frames Considered in TGn as a distinct stream from regular management frames Must be treated as a separate stream from data frames and other management frames TGw should not preclude other Task Groups (present and future) from defining new frame types/subtypes that require protection but that don't fit into existing protected streams. Henry Ptasinski, Broadcom

Ensuring Unique Streams: Why? September 2006 Ensuring Unique Streams: Why? Reuse of nonce by transmitter destroys confidentiality property of CCM Today: common transmit PN specified for all data streams built in as an optimization only TID included in nonce generation receiver is ensured replay counter is unique to its class: e.g. matching the current TID, even if same PN is used in different streams (either by poor xmit implementation or by attacker), since TID included in nonce Henry Ptasinski, Broadcom

Approaches to ensuring Unique Streams for Management Frames September 2006 Approaches to ensuring Unique Streams for Management Frames Do Nothing Split PN Add Flag to “priority octet” to differentiate management from data streams Henry Ptasinski, Broadcom

September 2006 Aproach 1: Do Nothing Receiver needs new/different replay counter for management frames Nonce for data AC_V0 or data w/o any QoS header is indistinguishable from management frame nonce Is it safe for receiver to not compare received PN with replay counter for both data AC_V0 and management frame? How does the receiver deal with reordering between the two streams? Cross streams can lead to recovery of plaintext! Henry Ptasinski, Broadcom

Approach 2: Split PN space September 2006 Approach 2: Split PN space One partitioning: upper 1/2 of range used for management frames receiver needs new replay counter for management frames if PN is out of valid range for frame type, reject frame Appears to work for management vs. data frame split, even allowing for possible future prioritized management frames But what about: compatibility issues with legacy (non-TGw) STAs? Legacy will not know to check for this new partitioning: legacy susceptible to attack does not deal with TGn embedded management frame how to deal with other new frame types/subtypes that need protection in a straightforward fashion? failure modes? error cases? Henry Ptasinski, Broadcom

Approach 3: Add Flag in “Priority Octect” to Explicitly Distinguish September 2006 Approach 3: Add Flag in “Priority Octect” to Explicitly Distinguish Receiver still needs new replay counter for management frames but can use same rules as 802.11i Allows for possible future prioritized management frames Reserve remaining 3 bits in "priority" octet for future use Allows for straightforward future expansion Henry Ptasinski, Broadcom

Move to include normative text in document 1063/r1 into the TGw draft. September 2006 Motion Move to include normative text in document 1063/r1 into the TGw draft. Mover: Seconder: Results: Henry Ptasinski, Broadcom