1. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 1 Can KCK be used to protect 802.11r 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: September 2006 Authors:

2. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 2 KCK Overview KCK is used to authenticate 802.1X packets TGr has defined construction that require authentication of (Re)Association and newly defined 802.11 authentication frames Authenticity validation of both 802.1X and TGr 802.11 authentication and (Re)Association frames can be defined to be in the SME Can the KCK be used for authenticating both ?

3. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 3 Re-Using KCK for two applications The same KCK may be used for two applications: e.g. 802.1X and 802.11 authentication and (re)association frames if: The processes are within the same cryptographic boundary (or hold a trust relationship) The construction are unique to ensure no collisions can occur –How do we ensure unique constructions for both?

4. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 4 802.1X EAPoL Key Frame Construction Descri ptor Type Key Info Key Lengt h Key Repla y Count er Key Nonce IVRSCReser ved Key MIC Key Data Lengt h Key Data 1 byte2 bytes 8bytes32byte s 16byte s 8bytes 16byte s 2bytesnbytes The Key MIC field is computed over the EAPoL Key Frame, from and including the EAPOL protocol version field to and including the Key Data field, calculated with the Key MIC field set to 0

5. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 5 Proposed TGr Authentication ST A M AC AP M AC Tra nsa ctio n Seq M DI E FTIERSN IE RIC Ele me nt ID (1) Len gth (1) MI C Co ntr ol (2) MIC (16) ANo nce (16) SNo nce (16) R0KH -ID (48) Option al Params 6 byt es 1 byt e 8by tes N bytesM bytes L bytes The MIC field is computed over the above encapsulation: –Transaction Sequence is set to either 5 or 3 only

6. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 6 How to ensure unique construction? Cryptographic algorithm must be the same for authenticating all constructions: e.g. both should use the same HMAC-MD5, HMAC-SHA1 or HMAC- SHA2 As fields may vary in either EAPoL Key frame and TGr encapsulation, at least 1 bit must be guaranteed to be unique Approaches: 1.Define a byte field in the encapsulations 2.Prepend unique label strings to the MIC computations

7. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 7 Define a common byte field The EAPoL version field could also be adopted in the TGr encapsulation for such a purpose Pros: Enables the EAPoL logic to stay the same Cons: binds and creates interdependency between the EAPoL version for EAPoL Key frames and 802.11 frames

8. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 8 Prepend Unique Label strings EAPoL Key Frames now authenticated with: –HASH-Function( KCK, “EAPoL Key frame authentication” || EAPoL Key frame-with-MIC-set-to-0) TGr authenticated as: –HASH-Function( KCK, “802.11r authentication” || SPA || TAP || Transaction-Sequence || MDIE || FTIE-with-MIC-set-to-0 || RSNIE || RIC) Pros: independent constructions Cons: requires update to EAPoL construction, though that can be negotiated as part of TGr capability

9. doc.: IEEE 802.11-06/01456r0 Submission September 2006 Cam-Winget, Fluhrer, McGrew, Cisco Systems Slide 9 Comments?