1. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 1 RSC Pools for Mgmt Frames 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: July, 2006 Author:

2. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 2 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)

3. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 3 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

4. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 4 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

5. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 5 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

6. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 6 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” 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) Need to change the 48-bit PN allocation and replay check for mgmt frames

7. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 7 Guaranteeing Uniqueness with PN Transmitter allocates PNs of both mgmt and QoS-free data frames Simply allocate PNs starting from 0xffffffffff and subsequently decrease them 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

8. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 8 How can Receiver Guarantee Unique PNs? Receiver maintains separate RSCs for QoS-free data and mgmt frames Change mgmt frame replay check procedure to ensure PN decreases and to check for collision against the QoS-free data frames Any frame which lacks a QoS Control field is checked against one MAC-state counter, 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

9. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 9 Questions?

10. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 10 Motion 1 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.

11. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 11 Motion 2 Instruct the TGw editor to make the following change: The PN values used for robust management frames shall be drawn from a counter starting at 0xffffffffff and the replay check process shall enforce the values are decreasing.

12. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 12 backup

13. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 13 Output Scheduling PN = 11 PN = 9 PN = 12 PN = 13 Priority Scheduler PN = 13 Low Prio Hi Prio

14. doc.: IEEE 802.11-06/0848-r2 Submission July 2006 K.HayesSlide 14 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…