RSC Pools for Mgmt Frames Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2006 RSC Pools for Mgmt Frames Date: July, 2006 Author: 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>. K.Hayes John Doe, Some Company
Replay Checking review Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2006 Replay Checking review With a single session flow, frames must be sent in an ordered sequence across the link – frames cannot be reordered within the session lest security checks declare a replay violation For multiple sessions, the rule above still holds, but frames may be reordered across sessions (i.e. output scheduling may occur) K.Hayes John Doe, Some Company
Crypto Transmit Sequencing July 2006 Crypto Transmit Sequencing TKIP and CCMP require replay checking as receiver operation Verification is done with Packet Numbers (PN) built from the IV, extended IV Transmitter allocates all PNs in the sequence received from the network stack, even for multiple sessions; gaps in the increasing PN sequence are allowed PNs must never be reused with the same RSN key within the same session K.Hayes
July 2006 What’s a session? Strictly speaking this is a set of 802.11 frames with: A QoS control field with the same TID - OR- No QoS control field at all For TGw, management frames are the second category There is no QoS control field…and certainly no TID! Therefore, management frames use the same session as QoS-free data frames K.Hayes
Crypto Receive Sequencing July 2006 Crypto Receive Sequencing Multi-session receiver cannot use a single Receive Sequence Counter (RSC) to do replay checks; it must have N counters, where N is the number of sessions Data frames are “steered” into a discrete RSC bin indexed by their QoS Control Field’s 4-bit TID, or another bin if QoS Control Field is absent from frame header K.Hayes
Management Frame Crypto Construction July 2006 Management Frame Crypto Construction Clauses 8.3.3.3.2 and 8.3.3.3.3 state frames with no QoS Control field do not include any “priority” in their AAD and shall use 0x00 in their Nonce construction Management frames have no QoS Control Field in their 802.11 header and therefore need no “priority octet” No need to change the 48-bit PN allocation for mgmt frames It would be incorrect to overload/subvert the MIC/Nonce input field labeled as “priority” with an arbitrary value because uniqueness is already easy to guarantee (and implement) K.Hayes
Guaranteeing Uniqueness with PN July 2006 Guaranteeing Uniqueness with PN Transmitter allocates PNs of both mgmt and QoS-free data frames Simply allocate PNs from the same pool by maintaining a single counter for both! Using single counter is easiest way to implement this with a single thread If mgmt and data are transmitted by separate threads/CPUs, then let both threads access a single counter NO CHANCE of keystream collision since all PNs are unique for all sessions (with or without QoS control field) Transmitter provides uniqueness across all frames lacking QoS control field Receiver verifies uniqueness by using a single counter for all frames lacking QoS control field K.Hayes
How can Receiver Guarantee Unique PNs? July 2006 How can Receiver Guarantee Unique PNs? Receiver uses a single counter for frames lacking QoS Control field ALL frames which lack a QoS Control field are checked against a MAC-state counter, just like in 802.11i Receiver performs replay check, just like in 802.11i If attacker is able to inject a frame with no QoS control in the air, receiver will detect it and drop the frame, just like in 802.11i Easy to guarantee, easy to implement, compatible with data cipher suite K.Hayes
July 2006 Questions? K.Hayes
Motion Move to instruct TGw editor to make following changes: July 2006 Motion Move to instruct TGw editor to make following changes: The 0xff value used as input to the TKIP MIC and CCMP MIC for management frames shall be removed from those calculations as in accordance with clause 8.3.3.3.2 The 0xff value used as input to the CCMP Nonce for management frames shall be set to 0x00 as in accordance with clause 8.3.3.3.3 The PN values used for robust management frames shall be drawn from the same pool as for data frames containing no QoS control field K.Hayes
July 2006 backup K.Hayes
Output Scheduling July 2006 Low Prio PN = 11 PN = 9 Priority Scheduler Hi Prio PN = 13 K.Hayes
Other examples of MAC state July 2006 Other examples of MAC state moreData status Power Management state 802.11 sequence number 802.11 fragment number and fragmentation state MIB variables Crypto keys Ad nauseum… K.Hayes