1. doc.: IEEE 802.11-05/01097r0 Submission November 2005 N. Cam-Winget, K. Sood, and J. WalkerSlide 1 EAPKIE Replay Counters and MIC 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: 9 November 2005 Authors:

2. doc.: IEEE 802.11-05/01097r0 Submission November 2005 N. Cam-Winget, K. Sood, and J. WalkerSlide 2 802.11r Use of EAPOL Key Replay Counters Problem statement: Do the encapsulated EAPOL Key frames (e.g. EAPKIE) need to validate the Key Replay Counters? 802.11i defines use of EAPOL Key replay Counters to prevent replays of EAPOL Key updates. 802.11r optimizes Key updates by enabling the use of EAPOL Key frames encapsulated in new 802.11 Authentication frames and (Re)association frames

3. doc.: IEEE 802.11-05/01097r0 Submission November 2005 N. Cam-Winget, K. Sood, and J. WalkerSlide 3 Base Mechanism EAPKIE in (Re)Association Request and Response are used to prove liveness of PTK. (Re)Association Request and Response are authenticated by the EAPKIE MIC. (Re)Association Messages must be bound to 11r Authentication Request: –(Re)Association Request must echo TAP’s ANonce –(Re)Association Response must echo STA’s SNonce EAPOL Key Replay Counter validation not applicable in EAPKIE –Key Replay counter is initialized to 0 after successful (re)association TAPTSTA 11r Auth Req( FT STA, MD STA, RSN STA, EAPK[SNonce, R1Name]) 11r Auth Resp( FT TAP, MD TAP, RSN TAP, EAPK[ANonce, R1Name]) (Re)Assoc Req( FT STA, MD STA, RSN STA, RIC-Request, EAPK[ANonce, R1Name, MIC]) (Re)Assoc Resp( FT TAP, MD TAP, RSN TAP, RIC-Response, EAPK[SNonce, R1Name, MIC])

4. doc.: IEEE 802.11-05/01097r0 Submission November 2005 N. Cam-Winget, K. Sood, and J. WalkerSlide 4 Fast Transition with Pre-Reservation EAPKIE in 11r Auth Confirm/ACK are used to prove liveness of PTK. EAPKIE in (Re)Association Request/Response are used to confirm pre- reservation of both PTKSA and QoS Resources (Re)Association Request/Response are bound by SNonce and ANonce (Re)Association Messages reflect contents of 11r Auth Confirm/ACK: protection MUST include 802.11 packet header TAPTSTA 11r Auth Req( FT STA, MD STA, RSN STA, EAPK[SNonce, R1Name]) 11r Auth Resp( FT TAP, MD TAP, RSN TAP, EAPK[ANonce, R1Name]) 11r Auth Confirm( FT STA, MD STA, RSN STA, RIC-Request, EAPK[SNonce, R1Name, MIC ]) 11r Auth ACK( FT TAP, MD TAP, RSN TAP, RIC-Response, EAPK[ANonce, R1Name, MIC ]) (Re)Assoc Req( FT STA, MD STA, RSN STA, RIC-Request, EAPK[ KRC, SNonce, R1Name, MIC ]) (Re)Assoc Resp( FT TAP, MD TAP, RSN TAP, RIC-Response, EAPK[ KRC, ANonce, R1Name, MIC ])

5. doc.: IEEE 802.11-05/01097r0 Submission November 2005 N. Cam-Winget, K. Sood, and J. WalkerSlide 5 Updates to 802.11i and 11r draft 0.09 No EAPKIE Key Replay counter validation required as they must match the SNonce and ANonce provided in either the 802.11r Authentication or Fast Transition Action frame sequence. EAPKIE MIC must protect 802.11 Header –802.11 Header protection is required to distinguish 802.11 Authentication Confirm/ACK, Fast Transition Confirm/ACK and (Re)association Request/Response –802.11 Header protection includes all fields except for: Frame Control field: the Retry (bit 11), Power management (bit 12) and More Data (bit 13) subfields are muted to 0 and the Protected subfield (bit 14) must be set to 1. Duration field: this field shall be muted to 0 Sequence control field: this field shall be muted to 0