1. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 1 TGr Security Architecture 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: 2006-04-19 Authors:

2. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 2 TGr Security Design Instrument this design in context of state machines and in relation to 802.1X

3. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 3 TGr Security Architecture

4. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 4 TGr PTK Key Derivation

5. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 5 TGr Key Hierarchy (Contd.) R0KH receives MSK from AS R0KH derives PMK-R0 from MSK R0KH generates multiple PMK-R1 keys and sends to R1KHs PTK Keys –4 keys: KEK, KCK-11, TK, KCK-1X –KEK and KCK-11 are consumed by SME: SME uses KEK to wrap KDEs and KCK11 to MIC 11r frames –KCK-1X is consumed by.1X used to MIC.1X frames –KCK-1X authenticates GTK updates and TKIP countermeasures

6. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 6 TGr Initial Association

7. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 7 TGr Initial Association ANonce R0KH and R1KH are within the same crypto boundary –Because the R0KH and R1KH both need assurance that the ANonce is fresh and unpredictable ANonce was mixed into the key hierarchy to give distinct PMK-R1 Names. Four alternatives are discussed: –Extend additional keying material in PMK-R0 for use in PMK-R0 Name derivation –Extend additional keying material in PMK-R1 for use in PMK-R1 Name derivation –Use of EAP-Session-Id in PMK-R0 Name derivation –Have R1KH and R0KH generate independent ANonces, and deliver both to the STA

8. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 8 TGr FT Reassociation – Base Mechanism

9. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 9 GTK Updates Either the SME or the 802.1X can trigger the GTK update Message format and flow remains the same as 11i 802.1X requests SME to wrap KDEs On AP, 802.1X originates the GTK update messages Supplicant asks SME to unwrap and plumb GTK into MAC

10. doc.: IEEE 802.11-06/0566r1 Submission May 2006 Sood, Walker, Cam-Winget, CalhounSlide 10 TGr Design Impacts No EAPOL-Key Frames (EAPKIE) in any 11r messages Existing 11r message formats will need to be modified A separate MIC IE within the TGr messages Over-the-Air and Over-the-DS end-to-end message contents can be harmonized, since both will now be processed by the SME Security sections need to be modified to include this architecture, update key hierarchy Either duplicate the 11i state machine to adjust for 11r Initial Association, OR, add a flag in 11i state machine to make it use 11r key as opposed to 11i PMK