RSC Pools for Mgmt Frames

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0848-r2 Submission July 2006 K.HayesSlide 1 RSC Pools for Mgmt Frames Notice: This document has been prepared to assist IEEE
Advertisements

Doc.: IEEE /XXXXr0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 1 Constructing unique key streams for Management Frame Protection Notice:
Use of KCK for TGr Management Frame Protection
LB84 General AdHoc Group Sept. Closing TGn Motions
LB84 General AdHoc Group Sept. Closing TGn Motions
[ Interim Meetings 2006] Date: Authors: July 2005
Motions Date: Authors: January 2006
London TGu Motions Authors: January 2007 Date: Month Year
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
RSC Pools for Mgmt Frames
TGp Closing Report Date: Authors: July 2005 Month Year
TGp Closing Report Date: Authors: July 2007 Month Year
Attendance and Documentation for the March 2007 Plenary
Attendance and Documentation for the March 2007 Plenary
[ Policies and Procedure Summary]
[ Policies and Procedure Summary]
Motion to accept Draft p 2.0
3GPP liaison report July 2006
[place presentation subject title text here]
Descriptive Language Usage in TGv
JTC1 Ad Hoc Closing Report
Motions Date: Authors: January 2006
Fast Transition Mobility (FTM) Domain
TGp Motions Date: Authors: November 2005 Month Year
TGp Closing Report Date: Authors: March 2006 Month Year
TGu-changes-from-d0-02-to-d0-03
TGp Closing Report Date: Authors: May 2007 Month Year
TGn Frame Format Ad Hoc Status and Motions
CCMP Nonce Construction
JTC1 Ad Hoc Mid-week Report
TGp Closing Report Date: Authors: March 2006 Month Year
Reflector Tutorial Date: Authors: July 2006 Month Year
TGv Redline D0.07 Insert and Deletion
TGv Redline D0.06 Insert and Deletion
Experimental DTV Sensor
IEEE WG Opening Report – July 2008
ADS Study Group Mid-week Report
Attendance for July 2006 Date: Authors: July 2006
Attendance for November 2006
TGu-changes-from-d0-01-to-d0-02
CCMP Nonce Construction
LB73 Noise and Location Categories
TGy draft 2.0 with changebars from draft 1.0
TGv Redline D0.10 Insert and Deletion
TGn LB84 – Frame Format Ad Hoc Status and Motions
IEEE WG Opening Report – July 2007
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Attendance for July 2006 Date: Authors: July 2006
TGu-changes-from-d0-02-to-d0-03
[ Policies and Procedure Summary]
Beamforming and Link Adaptation Motions
Questions to the Contention-based Protocol (CBP) Study Group
TGn LB84 – Frame Format Ad Hoc Status and Motions
Motion to go to Letter Ballot
EC Motions – July 2005 Plenary
TGu-changes-from-d0-04-to-d0-05
for video transmission, Status
TGp Closing Report Date: Authors: January 2006 Month Year
TGu-changes-from-d0-03-to-d0-04
TGu Motions Date: Authors: May 2006 May 2006
Attendance for November 2006
Beamforming and Link Adaptation Motions for LB 84 Comment Resolutions
TGn LB84 – Frame Format Ad Hoc Motions
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Use of KCK for TGr Management Frame Protection
Use of KCK for TGr Management Frame Protection
TGr Proposed Draft Revision Notice
TGp Motions Date: Authors: January 2006 Month Year
Presentation transcript:

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