WPA 80211 v3 1 090922

Wi-Fi Protected Access
(WPA)
Enhanced Security
Implementation Based on IEEE
P802.11i standard
Version 3.1
August, 2004
Wi-Fi Alliance
3925 West Braker Lane
Austin, TX 78759
Phone: 512-305-0790
Fax: 512-305-0791
www.wi-fi.org
"Wi-Fi®" and the Wi-Fi logo are the registered trademarks of the Wi-Fi Alliance. "Wi-Fi
CERTIFIED" and "Wi-Fi Alliance," their respective logos, and "Wi-Fi Protected Access" are the
trademarks of the Wi-Fi Alliance.
Copyright 2004 Wi-Fi Alliance. All Rights Reserved.
WI-FI ALLIANCE PROPRIETARY – SUBJECT TO CHANGE WITHOUT NOTICE
The Wi-Fi Alliance owns the copyright in this document and reserves all rights therein.
This document and any related materials may only be used by Wi-Fi Alliance members for
their internal use, such as quality assurance and pre-certification activities, and for their
participation in approved Wi-Fi Alliance activities, such as the Wi-Fi Alliance certification
program, unless otherwise permitted by the Wi-Fi Alliance through prior written consent.
A user of this document may duplicate and distribute copies of the document in connection
with the authorized uses described above, provided any duplication in whole or in part
includes the copyright notice and the disclaimer text set forth herein. Unless prior written
permission has been received from the Wi-Fi Alliance, any other use of this document and
all other duplication and distribution of this document are prohibited. Unauthorized use,
duplication, or distribution is an infringement of the Wi-Fi Alliance’s copyright.
Version 3.1 – August 2004

Wi-Fi Protected Access (WPA)
Abstract
This document captures those clauses of IEEE P802.11i
standard that comprise an enhanced security implementation
based on IEEE P802.11i known as Wi-Fi Protected Access.
Implementation notes are provided.
i
Contents
WI-FI PROTECTED ACCESS (WPA) .................................................................. I
1 INTRODUCTION ..........................................................................................1
1.1 Abbreviations and Acronyms................................................................................................. 2
2 WPA OVERVIEW .........................................................................................5

2.1 Advertisement of WPA Availability ...................................................................................... 8
2.2 Authentication and Association Overview............................................................................ 9
2.3 ASCII Password Support for Pre-Shared Key................................................................... 29
3 TEMPORAL KEY INTEGRITY PROTOCOL ..............................................30

3.1 Active Countermeasures....................................................................................................... 30
3.2 Multicast/Broadcast Data Packets to AP ............................................................................ 35
3.3 TKIP and Michael Implementation Checklist.................................................................... 35
4 LAYER MANAGEMENT UPDATES...........................................................37
5 MAC SUBLAYER MANAGEMENT UPDATES ..........................................37
APPENDIX A: TKIP ALGORITHM REFERENCE IMPLEMENTATIONS AND

TEST VECTORS ................................................................................................38
APPENDIX B: MICHAEL REFERENCE IMPLEMENTATION AND TEST

VECTORS ..........................................................................................................38
APPENDIX C: WPA INFORMATION ELEMENT REFERENCE

IMPLEMENTATION............................................................................................38
APPENDIX D: ASCII PASSWORD REFERENCE .............................................43
APPENDIX E: IEEE 802.1X STATE SYNCHRONIZATION ...............................44
APPENDIX F: MICHAEL COUNTERMEASURES STATE MACHINES ............44
APPENDIX G: WPA REQUIREMENTS .............................................................50
Version 3.1 – August 2004 ii

APPENDIX H: SUGGESTIONS FOR RANDOM NUMBER GENERATION ......51
Figures
Figure 1—Global Pre-Shared State Machine ................................................................... 12
Figure 2—Supplicant Key Management State Machine .................................................. 17
Figure 3—Authenticator State Machine ........................................................................... 23
Figure 4—Authenticator Countermeasures ...................................................................... 31
Figure 5—Supplicant Countermeasures ........................................................................... 32
Figure 6—System Structure.............................................................................................. 44
Figure 7—Client STA MAC, Part 1 ................................................................................. 45
Figure 8—Client STA MAC, Part 2 ................................................................................. 46
Figure 9—Client STA Higher Layer Software................................................................. 47
Figure 10—AP MAC........................................................................................................ 48
Figure 11—AP Higher Layer Software ............................................................................ 49
Version 3.1 – August 2004 iii

1 Introduction
Wi-Fi Protected Access (WPA) is a subset of IEEE P802.11i, IEEE Standard for
Information Technology, Telecommunications and Information Exchange between
systems, Local and metropolitan area networks, Specific requirements; Part 11: Wireless
Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment
6: Medium Access Control (MAC) Security Enhancements, which satisfies certain
requirements of the full IEEE P802.11i standard.
Unless otherwise specified, all references in this document to clauses refer to the IEEE
P802.11i standard.
Some of the most significant Wi-Fi Protected Access features include the following:
1. WPA supports two authenticated key management protocols in infrastructure
mode, using 802.1X with pre-shared key and with extensible authentication
protocol (EAP) authentication. A simple independent basic service set (IBSS)
approach is described for reference but not supported in WPA. The IBSS
approach described uses no authenticated key management protocol but instead a
pre-shared key directly as the encryption/integrity key. (Note: IBSS is much
reduced in security because it has no key management.)
2. Access points (APs) and Stations shall use IEEE 802.11 open authentication when
they use WPA. The 802.11 MAC state machine is the same as the existing state
machine in Figure 8 of the IEEE 802.11 1999 (R2003) standard.
3. APs must advertise what they support (cipher suite, authentication modes).
Stations must request the cipher suites and authenticated key management
protocol they want. A propriety information element in the Beacon and probe
response messages is used to carry this information. The station uses the same
information element in association request message.
This is described in Section 2.1 and Appendix C.
4. Authentication and Association are required.
This is described in Section 2.2.
5. Temporal key integrity protocol (TKIP) encryption with the Michael integrity
check is required.
TKIP and Michael are described in Section 3.3.
6. WPA does not perform an integrity check on management and control messages.
7. WPA does not support preauthentication for fast handoff.
8. Management information base (MIB) support is as follows:
Station:
Implementations of WPA will need a configuration utility (or similar) to
configure the pre-shared key. (This is implementation dependent and will not
be defined here.) The pre-shared key shall be a 256bit key (because it is used
as the pairwise master key (PMK), and the implementation will need to enter
Version 3.1 – August 2004 1

this value either as a 256bit key via hex or via an American Standard Code for
International Interchange (ASCII) password. The key must be entered as 64
hex characters, although entering the key in a different format may be
possible. If the key is entered as an ASCII password, the 256bit key must be
generated as described in Section 2.3.
A station shall be able to configure a different pre-shared key for each service set
identifier (SSID).
Configuration of cipher suites is also supported. (This is implementation dependent and
will not be defined here.)
AP:
Implementations of WPA will need a configuration utility (or similar) to
configure the pre-shared key. (This is implementation dependent and will not
be defined here.) The pre-shared key shall be a 256bit key, and the
implementation will need to enter this value either as a 256bit key via hex or
via an ASCII password. The key must be entered as 64 hex characters
although entering the key in a different format may be possible. If the key is
entered as an ASCII password, the 256bit key must be generated as described
in Section 2.3.
The AP control panel will also need to provide configuration for the interval
at which 802.1X will update the group key. (This is implementation
dependent and will not be defined here.)
Configuration of cipher suites is also supported. (This is implementation
dependent and will not be defined here.)
802.1X on the AP needs to be able to configure temporal keys into the 802.11
MAC. (This is implementation dependent and will not be defined here.)
1.1 Abbreviations and Acronyms

Abbreviation/Acronym Definition
ACK Acknowledgement
ASCII American Standard Code for International Interchange
AES Advanced Encryption Standard
AP Access Point
BSS Basic Service Set
BSSID Basic Service Set Identification
CCMP Counter Mode with CBC-MAC Protocol
DA Destination Address
EAP Extensible Authentication Protocol

EAPOL EAP over LANs (IEEE 802.1X)
ESS Extended Service Set
FCS Frame Check Sequence
GTK Group Temporal Key
IBSS Independent Basic Service Set (IBSS)
ICV Integrity Check Value
ID Identifier
IE Information Element
IV Initialization Vector
MAC Medium Access Control
MIB Management Information Base
MIC Message Integrity Code
MLME MAC sublayer management entity
MPDU MAC protocol data unit
MSDU MAC service data unit
OUI Organizationally Unique Identifier
PHY Physical Specifications
PMK Pairwise Master Key
PRF Pseudo-Random Function
PSK Pre-shared Key
PTK Pairwise Transient Key
QoS Quality of Service
RA Receiver Address
RSC Receive Sequence Counter
RSN Robust Security Network
RSNIE Robust Security Network Information Element
RX Receive or Receiver
SA Source Address
SME Station Management Entity
SSID Service Set Identifier

STA Station
TA Transmitter Address
TKIP Temporal Key Integrity Protocol
TX Transmit or Transmitter
WEP Wired Equivalent Privacy
WME Wireless Multimedia Extensions
WPA Wi-Fi Protected Access

2 WPA Overview
WPA supports the changes to the 1999 802.11 standard as described in the following
clauses of IEEE P802.11i:
• 7.1.3.1.9
• 7.2.2
• 7.2.3.1
• 7.2.3.4
• 7.2.3.6
• 7.2.3.9
• 7.2.3.10.
The framework and operation of WPA are described in the following clauses:
• 8.1
• 8.1.1 (TKIP only)
• 8.1.2
• 8.1.3
• 8.1.4
• 8.2 (including all subsections).
The following considerations will be useful in the development of a WPA
implementation.
APs advertise their capabilities in a WPA information element (IE). If the network
administrator does not want particular ciphers to be used, then they should not be
advertised in the WPA IE for the AP/station. APs/stations should also be capable of being
configured to either allow/not allow non-WPA stations to associate. When configured to
allow association of non-WPA stations, the multicast cipher shall be wired equivalent
privacy (WEP).
The configuration options an AP should support are as follows:
1. Selection of one or more station configurations to associate to the AP:
a. WPA
b. WEP
c. WEP rekeying by using the existing 802.1X EAP over LANs
(EAPOL)-key message
2. Selection of the list for WPA of available ciphers for unicast:
a. TKIP
b. AES
3. Pre-shared key for WPA that can be an ASCII passphrase or a 256bit key
5
4. WEP key for static WEP stations that can be 40 or 104bits in length.
The configuration options a station should support are as follows:
1. Selection of the AP configurations the station will associate to:
a. WPA
b. WEP
2. Selection of the cipher for WPA to use for unicast
a. TKIP
b. AES
3. Pre-shared key for WPA that can be an ASCII passphrase or a 256bit key
4. WEP key for static WEP stations that can be 40 or 104bits in length.
The use of pre-shared key is recommended for home use only. When the PSK is used as
the PMK, impersonation between stations or a station impersonating an AP is possible.
The multicast cipher must always be the lowest unicast cipher enabled. Thus, if WEP is
enabled in 1, then the multicast is WEP. If only WPA is enabled in 1, and TKIP is
enabled in 2, then the multicast cipher is TKIP.
Stations get the WPA information element from the Beacon or Probe Response messages.
Based on the station encryption/integrity capabilities and policy configuration of the
ciphers that the station is willing to communicate with, the station decides which APs it is
willing to use. The policy configuration may include the ciphers that the station is willing
to use, the authenticated key management that the station is willing to use, whether the
station is willing to allow Group keys to be used for unicast, etc.
If the station or AP receives a WPA information element with an authentication suite of
WPA, then it shall perform 802.1X authentication and 802.1X key management. If the
authentication suite is WPA-PSK, then the station or AP shall do 802.1X key
management.
(Note: 802.1X key management is the term used for managing the keys using IEEE
802.1X EAPOL-Key message, as described in Section 2.2.4, with modifications as
noted.)
If the station does not receive a WPA information element in the Beacon or Probe
Response, the station shall follow the normal 802.11 authentication. (This may include
the current 802.1X authentication.)
If the AP does not receive a WPA information element in the Association Request, the
AP shall follow the normal 802.11 association processing. (This may include the current
802.1X authentication.)
(Note: The AP shall have a way to disable non-WPA clients from associating.)
If the AP supports WPA and non-WPA stations, the following cases must be considered:
1. The non-WPA station supports an 802.1X supplicant that is a non-WPA 802.1X
supplicant. The AP can use 802.1X to send WEP key updates to the station. A

non-WPA supplicant only supports group keys, and the AP must track per station
whether it supports unicast keys.
2. The non-WPA station does not support an 802.1X supplicant. The WEP key must
be pre-configured into the non-WPA station and AP. Because the AP must use the
pre-configured key for broadcast/multicast traffic, it must use WPA key update
exchanges to send the key to the WPA stations. This means that the WPA stations
in this configuration will have fixed keys for broadcast/multicast traffic, although
they may use different keys for the unicast traffic if supported by the station and
AP. The AP shall use WPA Group key exchange to send the fixed WEP key to
the WPA stations.
When WPA and non-WPA stations are both enabled, it should be possible to enter a
default WEP key and disable group key updating to support case 2.
By default, group key updating should be enabled, and if 802.1X is enabled on the AP,
then 802.1X shall be used to update the group key on non-WPA stations.
The station then associates with the AP by using an association request message. The
association request message specifies the unicast and multicast ciphers it wants, given the
station’s cipher capabilities and configuration. When the station receives the association
response, it authenticates by using 802.1X with the AP. The AP sends an 802.11
association response message (with Reason code 1) if something in the WPA information
element was not recognized or accepted. When the AP receives the RADIUS accept, then
the AP sends an EAP-Success to complete the authentication at the station. The AP does
an EAPOL-Key message exchange with the station to set up the encryption/integrity keys
with the station and sets the Secure bit in the EAPOL-Key message when the initial keys
are sent to the station.
(Note: In general, reference in this document to sending an 802.11 disassociation and/or
802.11 deauthenticate message means that the 802.11 MAC sends the necessary
messages to get to state 1 between the source and destination stations, as shown in the
state machine diagram in Figure 8 in the IEEE 802.11 1999 standard.)
When a station or AP fills the WPA information element, the multicast cipher is from
multicast cipher selection, and the unicast cipher is from unicast cipher selection. If WPA
is enabled and there is no pre-configured key, then the authenticated key management is
WPA. Otherwise, the authenticated key management protocol is WPA-PSK if the
station/AP is in extended service set (ESS) mode; otherwise, it is WPA-None.
When all stations associated with an AP are 802.1X and WPA stations, and a station that
does not use 802.1X or WPA wants to associate, the new station must use the pre-
configured key for broadcast/multicast. The AP can use the knowledge of whether a non-
WPA station is associated to generate a multicast key with the existing stations as they
associated until a non-WPA station wants to associate, and then send the pre-configured
key to the existing stations (so that all stations will then be using the pre-configured key).
Otherwise, it can send the pre-configured key to all stations as they associate.
If the legacy station is configured to use default key 0 as the broadcast key, a WPA AP
must use the Unicast as Group key WPA capability bit to decide whether to use Pairwise
keys as encryption/integrity keys.
If an AP supports non-WPA open or shared stations, then the open or shared station
bypasses the 1X port switch. (Note: The security of such an AP is reduced, and there
shall be a way to disable non-WPA clients from associating to the AP.)
Table 1 describes various configuration options and the expected system behavior.
Table 1—Configuration Options and Expected System Behavior
Network Authentication Mode Encryption Manual Key 802.1X

Type or Authenticated Key Status Required?* Enabled?
Management
ESS Open None No No
ESS Open WEP Optional Optional
ESS Shared None Yes No
ESS Shared WEP Optional Optional
ESS WPA WEP No Yes
ESS WPA TKIP No Yes
ESS WPA AES No Yes
ESS WPA-PSK WEP Yes Yes
ESS WPA-PSK TKIP Yes Yes
ESS WPA-PSK AES Yes Yes
IBSS Open None No No
IBSS Open WEP Yes No
IBSS Shared None Yes No
IBSS Shared WEP Yes No
IBSS WPA-None WEP Yes No
IBSS WPA-None TKIP Yes No
IBSS WPA-None AES Yes No
*Whether a manual key is required for this mode to work
2.1 Advertisement of WPA Availability

Advertisement of WPA availability will be done by a propriety information element in
the beacon, probe response, association request, and re-association request messages. The
beacon and probe response messages advertise the AP capabilities; the association
request and re-association request messages contain the configuration that the station has
chosen for its association. The beacon or probe response messages contain the
capabilities of an IBSS station.

WPA uses the robust security network (RSN) Information Element described in Clause
7.3.2.25 with the following changes:
• The element identifier (ID) shall be 221 instead of 48.
• An additional 4 octets shall be inserted before the Version field containing an
organizationally unique identifier (OUI) and type fields of 00:50:F2:01.
• The OUI shall be 00:50:F2 instead of 00:0F:AC.
• WPA does not support counter mode with CBC-MAC protocol (CCMP); it
reserves the codes (per Table 21) without defining the encryption schemes.
• WPA has TKIP as a default rather than CCMP.
• The preauthentication bit (Clause 7.3.2.25.3 and Figure 46tc of IEEE P802.11i
shall always be 0.
• When the information element is used in an association request message or probe
response for IBSS stations, a maximum of one authenticated key management
suite and a maximum of one unicast cipher suite are allowed.
• Clause 7.3.2.25—The PMKID Count and PMKID List in the RSNIE are not used
in WPA.
• Clause 7.3.2.25.3—RSN Capabilities, the GTKSA and PTKSA Replay counter
flags are not used in WPA.
• All occurrences of “00 0F AC” shall be replaced with “00 50 F2.”
(Note: “WPA IE” refers to WPA’s adaptation of the RSN IE.)
(Note: “Authenticated Key Management using pre-shared key over 802.1X” means that
any station (STA) that has the key can impersonate any other station STA.)
(Note: If an advanced encryption standard (AES) cipher is used for unicast or for
multicast, then the AES EAPOL-Key format key descriptor from IEEE P802.11i must be
used.)
(Note: An AP that does not install the Pairwise keys means that stations can impersonate
each other.)
(Note: Element ID 221 is also used for vendor extension. STAs shall ignore information
elements with ID 221 that do not contain the value 00:50:F2:01 in the additional four
bytes inserted before the version field if they do not know how to process them.)
2.2 Authentication and Association Overview

Connecting to an AP consists of the following operations:
1. Select a network (i.e., specify a SSID).
2. Find nearby APs for the selected SSID.
3. Associate to chosen APs.
4. Initiate 802.1X-authenticated key management.

5. Install keys obtained from authenticating to the AP.
1 is internal to the management entity choosing the SSID for 2.
2 is the management entity calling MAC sublayer management entity (MLME)-
Scan.Request.
3 is the management entity associating to a basic service set (BSS).
4 is the management entity initiating 802.1X-authenticated key management by sending
an AuthenticationRequest to the Supplicant.
5 is the management entity calling MLME-SetKeys.Request.
Roaming can be done by:
1. (Re-)Associating and then performing 802.1X authentication. In this case, the
station repeats the same actions as for an association, but the encryption/integrity
keys are removed from the encryption/integrity engine when roaming away from
the AP from which the keys were obtained. The station shall delete the keys when
it disassociates/deauthenticates from all BSSs in the ESS.
Connecting to an IBSS station consists of the following operations:
1. Select a network (i.e., specify a SSID).
2. Find a nearby WPA IBSS station for the selected SSID.
3. Install the pre-shared key.
1 is internal to the management entity choosing the SSID for 2.
2 is the management entity calling MLME-Scan.Request.
3 is the management entity calling MLME-SetKeys.Request.
2.2.1 Associate/Re-Associate
The following rules shall be applied:
1. A station must use IEEE 802.11 open authentication.
2. A station must complete 802.1X, and obtain and install keys before attempting to
send class 3 data packets other than 802.1X.
3. An AP must complete 802.1X, and obtain and install keys before attempting to
send class 3 data packets on or off the DS for a station.
4. If the IEEE 802.1X authentication fails, a station may try again or attempt to
authenticate to another AP.
5. If the AP does not have the station authenticated, it shall send a deauthenticate
message to the station on receiving any message from that station.
6. If the AP fails during authentication, it sends a deauthenticate message.
7. An AP can delete a station’s state if required because of inactivity timeout,
resource shortages, etc. This occurs if the AP wants to recover the resources used

by a stations’ association. The AP should attempt to inform the station by sending
a deauthentication message.
8. IEEE 802.1X messages are sent in the clear if a Pairwise key for the station is not
installed and encrypted if a Pairwise key is installed. IEEE 802.1X messages are
not encrypted by using Group keys.
(Note: The use of Pairwise keys is more secure than the use of only Group keys,
because stations cannot spoof each others’ MAC address, and IEEE 802.1X
messages will be encrypted and protected against spoofing.)
9. If the AP cannot send the EAPOL-Key frame containing a Group key update to a
station, the AP may queue the message. If the AP deletes the message, the AP
shall send a deauthenticate message, and delete the association state by setting the
L2Failure event in the Authenticator state machine. The AP may not be able to
send the message because the station is out of range, asleep, etc. The
Authenticator state machine will eventually timeout the acknowledgement
message for the Group Key update, but the L2Failure optimizes the detection of
the failure.
2.2.2 Encrypted/Unencrypted Data Handling

Normally, the station and APs will send either encrypted data or unencrypted data
packets. The only unencrypted data packets allowed are unicast 802.1X data packets; and
unencrypted 802.1X data packets are allowed only when there is no Pairwise key
between the station and AP. Otherwise, unencrypted data packets must be discarded. If
the station and AP key state get out of synchronization, the following rules apply:
2.2.2.1 AP
If the AP receives a unicast encrypted packet that it does not have keys to decrypt, it
should send a disassociate message to the station and discard the data packet.
2.2.2.2 Station
On receiving a disassociate message or an 802.11 deauthenticate message, a station
should delete the Pairwise key and attempt to rejoin the network (i.e., reassociate to an
AP if the station was a member of an ESS).
2.2.3 Authentication and Key Management Overview

WPA uses the authentication and key management model as described in the following
clauses and adds support for a simple IBSS global pre-shared key system for optional
IBSS support.
2.2.3.1 Mandatory Authentication and Key Management

The authentication and key management model for WPA is based on 802.1X as described
in the following clauses:
• 5.1.1.4
• 5.1.1.5
• 5.2.2.2
• 5.4.2.2
• 5.4.2.3
• 5.4.3 and sub-clauses (references to TKIP only)
• 5.9 and sub-clauses, except that the GTK is not sent in the 4-Way Handshake, and
5.9.5 PMKSA caching is not used in WPA
• The security association management of WPA is described in the following
clauses:
• 8.4.1.1, except for text relating to pre-authentication, STAKey. GTK in 4-Way
Handshake, and IBSS
• 8.4.1.2 and sub-clauses, except for text relating to pre-authentication and IBSS
• 8.4.2 and sub-clauses, except for text relating to pre-authentication and IBSS
• 8.4.3.1
• 8.4.6, excluding 8.4.6.1 and 8.4.6.2
• 8.4.8, except that the GTK is not sent in the 4-Way Handshake; instead the Group
Key Handshake is used for the initial GTK delivery.
2.2.3.2 Optional IBSS Global Pre-Shared Key System

The following paragraph describes a simple approach to IBSS. IBSS is not supported in
WPA, and this paragraph is provided for information only. This system is meant for a
very simple IBSS usage. A pre-shared key is configured as a Group key, and no
authentication is carried out (even though IEEE 802.11 authentication frames are
exchanged). See Figure 1.
(Note: This does not provide the level of security that the Authentication Server system
provides. A data integrity failure can only be logged; it cannot cause a key change.)
Figure 1—Global Pre-Shared State Machine

(Note: When using TKIP, the two message integrity code (MIC) keys must be the same
because there is no Supplicant and Authenticator.)

(Note: A station using pre-shared keys in IBSS mode must remember the last
initialization vector (IV) it used with a particular pre-shared key and continue from that
point when using the key again.)
(Note: Saving the IV to nonvolatile storage every N packet and when loading the IV out
of the nonvolatile storage adding N to the IV can be used to reduce how often the IV
needs to be saved. A value of N of 1,000,000 means that if the system is restarted once
per minute and the system is transmitting packets as fast as possible over an 802.11a
MAC, the IV will last over 100 years.)
(Note: The IV shall be initialized to a random 48bit value when a stored IV is not
available.)
(Note: While a different IV can be used for each pre-shared key, sharing the IV across the
different pre-shared keys is possible. For example, it is possible to store a single IV for
use with all IBSS pre-shared keys. This reduces the information needed to be stored in
nonvolatile storage, at the expense of the time each pre-shared key can be used. The time
for a single IV is over 800 years, or 100 years with N = 1,000,000, sharing the IV does
not pose a problem.)
(Note: The station must track the receive IV for each station in range.)
2.2.4 EAPOL-Key Frames

WPA uses the EAPOL-Key frames of Clause 8.5.2, with the following definitions for the
Descriptor Type, Key Information Key index bits and Key Data Field. WPA does not use
the Encrypted Key Data Bit. The WPA EAPOL Protocol version field value shall be = 1,
as specified in IEEE 802.1X clause 7.5.3. STAKey messages are not supported in WPA.
Descriptor Type. This field is one octet and has a value of 254, identifying the WPA
Key Descriptor.
Key Information:
• Key Index (bits 4 and 5): specifies the key id of the temporal key of the key
derived from the message. The value of this shall be zero (0) if the value of Key
Type (bit 4) is Pairwise (1). The Key Type and Key Index shall not both be 0 in
the same message.
Group keys shall not use key id 0. This means that key ids 1 to 3 are available to
be used to identify Group keys. This document recommends that
implementations reserve key ids 1 and 2 for Group Keys, and that key id 3 is not
used.
The Key Type and Key Index shall not both be 0 in the same message.
• Reserved (bits 12-15). The sender shall set them to 0, and the receiver shall
ignore the value of these bits
Key Data. For EAPOL-Key messages specifying Pairwise Keys, the Key Data field will
contain the WPA IE in message 2 and 3 of the 4-way handshake and nothing for
messages 1 and 4.

For Pairwise Keys, this field contains the WPA IE contents (from and including the
element id) and the Key Data Length is set to the length of the information element
contents for messages 2 and 3 in the 4-way handshake. In messages 1 and 4, this
field is empty, and the Key Data Length is 0. The WPA IE will not be encrypted
when it is sent in the EAPOL-Key message.
The Supplicant should insert the WPA IE sent in its (re)associate request into the
second message of the 4-way handshake. On receipt of the second message, the
Authenticator shall compare this bitwise against the WPA IE received in the IEEE
802.11 request.
The Authenticator should insert the WPA IE sent in its Beacon or Probe Response
into the third message of the 4-way handshake. On receiving the third message, the
Supplicant shall compare the WPA IE bitwise against the WPA IE received in the
Beacon or Probe Response.
In either case, if the values do not match, then the receiver shall consider the WPA
IE modified and shall use the MLME-DEAUTHENTICATE.request to break the
association. A security error should be logged at this time.
For Group TKs, this field contains the encrypted GTK.
(Note: When checking the WPA information element, the length of the WPA information
element received in the beacon or probe response and sent in the associate request must
be checked against the length of the WPA information element specified in EAPOL-Key
Data Length.)
2.2.5 802.1X Authentication

WPA uses 802.1X as described in Clause 5.9 to provide the framework for AP/Station
authentication.
2.2.5.1 Key Hierarchy

WPA uses the TKIP and wired equivalent privacy (WEP) encryption key hierarchies
described in Clause 8.5.1 and sub-clauses for pairwise keys and group keys.
2.2.5.2 Mapping EAPOL Keys to 802.11 Keys

WPA uses Clause 8.6.1, Clause 8.6.2, Clause 8.6.5, and Clause 8.6.6 to describe the
mapping of the pairwise and group transient keys to the TKIP and WEP encryption
protocols, respectively.
2.2.5.3 Nonce Generation

WPA uses the nonce generation conventions defined in Clause 8.5.8.
(Note: A good source of a random number is required to initialize the Key Counter. If
not, the Key Counter may be predicable, and previous 4-way handshakes can be
replayed.)

2.2.5.4 Coordination of Authentication Process
2.2.5.4.1 ESS Authentication
Authentication in the ESS environment is described in Clause 8.4.6, with the exception of
references to pre-authentication and PMKSA caching, which are not supported in WPA.
2.2.5.4.2 4-Way Handshake

The 4-way handshake used by WPA is described in Clause 8.5.3 and its subclauses, with
the changes and corrections listed below. The notation used to describe the EAPOL-Key
frames is described in Clause 8.5.2.2.
The following changes shall be made to the text of IEEE P802.11i:
Clause 8.5.3.1—Key Data Length = 0. WPA does not include the PMKID in Key
Data.
Clause 8.5.3.3—Key Data Length = length in octets of the included WPA IEs. WPA
does not include the GTK in the Key Data field in the 4-Way Handshake.
2.2.5.4.3 Group Key Update

The handshake used by WPA for the group key update is described in Clause 8.5.4 and
its subclauses, with the changes and corrections listed below.
The following changes shall be made to the text:
Clause 8.5.4.1 – WPA uses different Key Data encryption and encapsulation. The
GTK KeyID is not included in the Key Data field.
Clause 8.5.4.2—The keyID is a “Reserved” field and must be set to zero and ignored
on receive.
2.2.5.4.4 Supplicant Request for Key Update
The Supplicant can request a key update by sending an EAPOL-Key frame with the
Request bit set. This is used when the MAC detects a data integrity attack.
If the EAPOL-Key frame has a key type of Pairwise key, the authenticator shall do a
4-way handshake with the Supplicant and then send a Group key update of the current
Group key to the Supplicant.
If the EAPOL-Key frame has a key type of Group key, the authenticator shall change the
Group key, do a 4-way handshake with the Supplicant, and do a Group key update to all
Supplicants.
A Michael MIC Failure message (refer to section 3.1) has the Request bit set, but does
not imply a request for key update. An AP receiving a correctly formatted Michael MIC
Failure message that passes the MIC test may optionally initiate a key update as
described in section 3.1.
2.2.5.4.5 Use of the Secure Bit
15
This is addressed in Clause 8.5.2.
2.2.5.4.6 Use of the EAPOL-Key Replay Counter

This is addressed in Clause 8.5.2.
(Note: The use acknowledgement (ACK) bit and Replay Counter are used to ensure that
all messages in the 4-way handshake and Group key update are unique. Each message
sent from the Authenticator must use a different replay counter and have the ACK bit set.
Replys to a message from the Authenticator must use the same replay counter value, and
the ACK bit must not be set. Messages sent by the supplicant not in response to a
message from the Authenticator must have the Request bit set, and the supplicant must
use its own replay counter.)
Sample 4-Way handshake
Message 1: MIC = 0, ACK = 1, Replay Counter = 0
Sample Group Key Update
2.2.5.4.7 Use of the EAPOL-Key Key Data for Pairwise Keys

This is addressed in the Key Data section of Clause 8.5.2, with the changes noted above
for Key Data field usage.
2.2.5.4.8 EAPOL-Key Encoding

This is addressed in Clause 8.5.2.2, with the changes noted above for Key Data field
usage.
2.2.5.4.9 4-Way Handshake

The 4-way handshake is described in Clause 8.5.3, with the exception that in Clause
8.5.3.3, the normal value of the Key RSC field is zero.
2.2.5.4.10 State Diagrams

Replace Clauses 8.5.6 and 8.5.7 with the following:
8.5.6 Supplicant key management state machine

There is one state machine for Supplicants. The Supplicant shall reinitialize the
Supplicant state machine (Figure 2) whenever its system initializes. A Supplicant
enters the AUTHENTICATION state on an event from the MAC that requests another
STA to be authenticated. A Supplicant enters the STAKEYSTART state on receiving

an EAPOL-Key messages from the Authenticator. If the MIC on any of the EAPOL-
Key messages fails, the Supplicant silently discards the packet.
AuthenticationFailed
AuthenticationRequest
DISCONNECTED AUTHENTICATION
StaDisconnect() SNonce = Counter++;
DeautheticationRequest || Init PTK = GTK[0..N] = 0;
CANonce = 0;
UCT 802.1X::VirtualSecure = False
802.1X::portControl = Auto;
802.1X::portMode = Enabled;
INITIALIZE
EAPOLKeyRecieved
MSK = 0
&& MICVerified
802.1X::portMode = Disabled
Remove PTK
Remove GTK(0..N)
802.1X:VirtualPort = True
EAPOLKeyRecieved
&& MICVerified
STAKEYSTART
StaProcessEAPOL-Key
Updatekeys IntegrityFailed
KEYUPDATE
SNonce = Counter++;
Remove PTK
Remove GTK[0..N]
Send EAPOL(0, 1 ,1 , 0, 0, P, 0, SNonce, MIC(PTK), 0)
IntegrityFailed = False
Updatekeys = False
UCT
Figure 2—Supplicant Key Management State Machine
UCT means the event triggers an immediate transition.
This state machine does not use timeouts, etc. The IEEE 802.1X state machine has
timeouts that recover from Authentication failures, etc.
The Management entity will send an AuthenticationRequest event when it wants an

Authenticator authenticated, this can be before or after the station associates to the
AP. In an IBSS environment the event will be generated when a Probe Response is
received.
8.5.6.1 Supplicant state machine states

DISCONNECTED: A STA’s supplicant enters this state when IEEE 802.1X
authentication fails. The supplicant executes StaDisconnect and enters the
INITIALIZE state.
INITIALIZE: A STA’s supplicant enters this state from the DISCONNECTED state,
when it receives disassociate or Deauthentication messages, or when the STA
initializes, causing the STA’s supplicant to initialize the key state variables.
AUTHENTICATION: A STA’s supplicant enters this state when it sends an IEEE

802.1X AuthenticationRequest to authenticate a BSSID.

STAKEYSTART: A STA’s supplicant enters this state when it receives an EAPOL-
Key message. All the information to process the EAPOL-Key message is in the
message and is described in procedure StaProcessEAPOL-Key.
KEYUPDATE: A STA’s supplicant enters this state when its STA requires a key
update from the authenticator. This may be because of a management event or
because of a data integrity failure occurs. From this state the supplicant sends an
EAPOL-Key message to the authenticator to update the transient keys. The Request
bit shall be set.
8.5.6.2 Supplicant state machine variables

DeauthenticationRequest – The Supplicant set this variable to TRUE if the
Supplicant’s STA reports it has received disassociate or Deauthentication messages.
AuthenticationRequest – The Supplicant sets this variable to TRUE if its STA’s IEEE
802.11 Management Entity reports it wants an SSID authenticated. This can be on
association or at other times.
AuthenticationFailed – The Supplicant sets this variable to TRUE if the IEEE 802.1X
authentication failed. The Supplicant uses the MLME-DISASSOCIATE.request to
cause its STA to disassociate from the authenticator’s STA.
EAPOLKeyReceived – The Supplicant sets this variable to TRUE when it receives

an EAPOL-Key message.
IntegrityFailed – The Supplicant sets this variable to TRUE when its STA reports that
a fatal data integrity error (e.g. Michael failure) has occurred.
Informative Note: A Michael failure is not the same as MICVerified since IntegrityFailed is
generated if the MAC integrity check fails, MICVerified is generated from validating the EAPOL-Key
MIC. Note also the STA does not generate this event for CCMP, since countermeasures are not
required.
MICVerified – The Supplicant sets this variable to TRUE if the MIC on the received
EAPOL-Key message verifies as correct. The Supplicant silently discards any
EAPOL-Key message received with an invalid MIC.
Counter – The Supplicant uses this variable as a global counter used for generating
nonces.
SNonce – This variable represents the Supplicant’s nonce.
PTK – This variable represents the current PTK.
TPTK – This variable represents the current PTK until the third message of the
4-way handshake arrives and is verified.
GTK[] – This variable represents the current GTKs for each group key index.
PMK – This variable represents the current PMK.
18
802.1X::XXX – denotes another IEEE 802.1X state variables XXX not specified
herein.
8.5.6.3 Procedures
STADisconnect. The Supplicant invokes this procedure to disassociate and
deauthenticate its STA from the AP.
RemoveGTK – The Supplicant invokes this procedure to remove the GTK from its
STA.
MIC(x) – The Supplicant invokes this procedure to compute a Message Integrity

Code of the data x.
CheckMIC() – The supplicant invokes this procedure to verify a MIC computed by

the MIC() function.
StaProcessEAPOL-Key – The Supplicant invokes this procedure to process a

received EAPOL-Key message. The pseudo code for this procedure is:
StaProcessEAPOL-Key (S, M, A, T, N, K, RSC, ANonce, GNonce, MIC, GTK)

TPTK ← PTK
TSNonce ← 0
UpdatePTK ← 0
State ← UNKNOWN
if M = 1 then
if Check MIC(PTK, EAPOL-Key message) fails then
State ← FAILED
else
State ← MICOK
endif
endif
if K = P then
if State ≠ FAILED then
if PSK exists then – PSK is a pre-shared key
PMK ← PSK
else
PMK ← Master Session Key from 1X
endif
TSNonce ← SNonce
TPTK ← Calc PTK(ANonce, TSNonce)
endif
if State = MICOK then
PTK ← TPTK
UpdatePTK ← TRUE
endif
else if State = MICOK then -- K = G
if GTK[N] ← Decrypt GTK succeeds then
if Set GTK(N, T, RSC, GTK[N]) fails then
invoke MLME-DEAUTHENTICATE.request
endif
else

State ← FAILED
endif

else
State ← FAILED
endif
if A = 1 and State ≠ FAILED then
Send EAPOL(0, 1, 0, 0, 0, K, 0, TSNonce, 0, MIC(TPTK), 0)
endif
if UpdatePTK = 1 then
if Set PTK(N, TRUE, RSC, PTK) fails then
invoke MLME-DEAUTHENTICATE.request
endif
if State = MICOK and S = 1 then
802.1X::VirtualSecure = TRUE
endif
Here UNKNOWN, MICOK and FAILED are values of the variable State used in the
Supplicant pseudo code. State is used to decide to do the key processing. MICOK is
set when the MIC of the EAPOL-Key has been checked and is valid. FAILED is used
when a failure has occurred in processing the EAPOL-Key message. UNKNOWN is
the initial value of the State variable.
Informative Note: A Supplicant shall only use Key Descriptor of type 254 and version 1 or 2 to and
from WPA Access Points; it shall ignore other Key Descriptor types and Versions.
Informative Note: EAPOL-Key messages with Key Type of Pairwise and a non-zero key index
should be ignored.
Informative Note: EAPOL-Key messages with Key Type of Group and an invalid key index should
be ignored.
Informative Note: The Replay Counter used by the Supplicant for EAPOL-Key messages that are
sent in response to a received EAPOL-Key message must be the received Replay Counter.
Informative Note: TPTK is used to stop attackers changing the PTK on the supplicant by sending
the first message of the 4-way handshake. An attacker can still affect the 4-way handshake while
the 4-way handshake is being carried out.
Informative Note: The PMK will be supplied by the authentication method used with IEEE 802.1X if
Pre-shared mode is not used.
Informative Note: Invalid EAPOL-Key messages such as invalid MIC, Group Key without a MIC,
etc. are ignored.
Informative Note: A PTK is configured into the encryption/integrity engine depending on the Tx/Rx
bit but if configured is always a transmit key. A GTK is configured into the encryption/integrity
engine independent of the state of the Tx/Rx bit but whether the GTK is used as a transmit key is
dependent on the state of the Tx/Rx bit.
CalcGTK(x) – Calculates the Group Transient Key (GTK) using GNonce as the
nonce input to the PRF.
DecryptGTK(x) – Decrypt the GTK from the EAPOL-Key message

SetPTK/GTK(x) – Sets the PTK/GTK into the encryption/integrity engine
Informative Note: On receiving the IEEE 802.1X EAP-Success message a Supplicant should
compare the received keys and the ciphers specified in the WPA information element for
consistency problems. E.g. the WPA information element specifies a unicast cipher but no Pairwise
Key was configured into the encryption/integrity engine.
8.5.7 Authenticator key management state machine

There is one state diagram for the GTK Authenticator. In an ESS the GTK
Authenticator will always be the AP, and in an IBSS environment will be a designated
machine.
The state diagram in Figure 3 consists of three state machines:
1. The first state machine (PTK state machine) uses the DISCONNECT,
DISCONNECTED, INITIALIZE, AUTHENTICATION, AUTHENTICATION2,
INITPMK, INITPSK, PTKSTART, PTKINITNEGOTIATING, PTKINITDONE,
UPDATEKEYS, INTEGRITYFAILURE, and KEYUPDATE states. An instance of
this state machine exists for each association and handles the initialization, 4-
way handshake, tear-down, and general clean-up.
2. The second state machine (PTK Group Key state machine) uses the
REKEYNEGOTIATING, KEYERROR and REKEYESTABLISHED states. An
instance of this state machine exists for each association and handles transfer of
the GTK to the associated client.
3. The third state machine (Group Key state machine) uses the SETKEYS and
SETKEYSDONE states. A single instance of this state machine exists on the
Authenticator. It changes the Group key when required, triggers all the PTK
Group Key state machines and updates the IEEE 802.11 MAC in the
Authenticator’s AP when all STAs have the updated Group key.
Since there are two GTKs, responsibility for updating these keys is given to the
Group Key state machine. That is, this state machine determines which GTK is in
use at any time. When a first STA associates, the Group Key state machine has not
been started and is started by GInitAKeys variable when the 4-way handshake
completes. The Group Key state machine initializes the value of the Group Key and
then triggers the PTK Group Key state machine, which actually sends the Group Key
to the associated station.
When a second STA associates, the Group Key state machine is already initialized,
and a Group Key is already available and in use. The PTK Group Key state machine
is immediately triggered from the PTKINITDONE state and sends the current Group
Key to the new station.
When the GTK is to be updated the GTKReKey variable is set. The SETKEYS state
updates the Group Key and triggers all the PTK Group Key state machines that
current exist—one per associated STA). Each PTK Group Key state machine sends
the Group Key to its station. When all the stations have received the Group Key (or
failed to receive the key), the SETKEYSDONE state is executed which updates the
22
APs encryption/integrity engine with the new key.
Disconnect
DISCONNECT
DeauthenticationRequest STADisconnect()
UCT
DISCONNECTED AUTHENICATION
GNoStations-- GNoStations++
PTK = 0;
Init 802.1X::portControl = Auto;
UCT 802.1X::portMode = Enabled;
ReAuthenticationRequest
INITIALIZE UCT
MSK = 0
GInitAKeys = PInitAKeys = IntegrityFailed = False AUTHENICATION2
If Unicast cipher supported by Authenticator
Pair = 1 ANonce = Counter++;
Remove PTK
802.1X:portSecure = 0
802.1X::authSuccess
PSK
INITPMK INITPSK
PMK = RadiusKey PMK = PSK
!RadiusKeyAvailable
GUpdateStationKeys
|| (GKeyReady && PInitAKeys) UCT
TimeoutEvt
TimeoutCtr>N RadiusKeyAvailable
REKEYNEGOTIATING
TimeoutEvt
PInitAKeys = False
GUpdateStationKeys = False
Send EAPOL(1, 1, 1, !Pair, GN, G, GNonce, MIC(PTK), GTK[GN]); PTK START
TimeOutCtr++ Send EAPOL(0, 0 ,1 , 0, 0, P, ANonce, 0, 0)
TimeOutCtr++
EAPOLKeyRecieved
&& K == Group EAPOLKeyRecvd
TimeoutCtr>N && MICVerified && K == Pairwise
REKEYESTABLISHED TimeoutEvt && MICVerified
KEYERROR Check MIC(PTK)
GKeyDoneStations--
GKeyDoneStations–- PTKINITNEGOTIATING
TimeOutCtr = 0 PTK = Calc PTK(ANonce, SNonce)
802.1X::portSecure = 1 Check MIC(PTK)
Send EAPOL(0, 1, 1, Pair, 0, P, ANonce, MIC(PTK), 0)
GTKAuthenticator &&
UCT (GTKReKey EAPOLKeyRecvd
|| (GInitAKeys && !GInitDone)) && K == Pairwise
TimeoutCtr>N
&& MICVerified
SETKEYS PTKINITDONE
GTKReKey = False
If GInitDone == False { Check MIC(PTK)
GTK[0..N] = 0; If Pair == 1
GN = 1 Set PTK(0, Tx/RX, PTK)
GM = 2 GInitAKeys = True
} PInitAKeys = True
Else
Swap(GM,GN) EAPOLKeyRecvd &&
GInitDone = True Request == True
GKeyDoneStations = GNoStations && MICVerified
GNonce = Counter++;
GTK[GN] = Calc GTK(GNonce); UPDATEKEYS
GUpdateStationKeys = True Check MIC(PTK)
GKeyDoneStations == 0 IntegrityFailed
IntegrityFailed
(Error == True)
SETKEYSDONE !IntegrityFailed
SetGTK(GN, Tx/Rx, GTK[GN]) (Error == False)
GKeyReady = True INTEGRITYFAILURE
IntegrityFailed = False UCT
If Group Key failure
GTKReKey = True
Waitupto60()
UCT
KEYUPDATE
ANonce = Counter++;
GNonce = Counter++;
UCT
Figure 3—Authenticator State Machine

23
Both the PTK state machine and the PTK Group Key state machine both use
received EAPOL-Key messages as an event to change states. The PTK state
machine only uses EAPOL-Key messages with the key type set to Pairwise key and
the PTK Group Key state machine only uses EAPOL-Key messages with the key
type set to Group key.
8.5.7.1 Authenticator state machine states

DISCONNECT: This state is entered as an EAPOL-Key message is received and
fails its message integrity code (MIC) check. It sends a deauthenticate message to
the Access Point and enters the INITIALIZE state.
DISCONNECTED: This state is entered when disassociate or deauthenticate

messages are received.
INITIALIZE: This state is entered from the DISCONNECTED state, when a

DeauthenticationRequest event occurs or when the station initializes. The state
initializes the key state variables.
AUTHENTICATION: This state is entered when an AuthentiationRequest is sent

from the Management entity to authentication a BSSID.
AUTHENTICATION2: This state is entered from the AUTHENTICATION state or

from the PTKINITDONE state.
INITPMK: This state is entered when the 802.1X backend authentication server
completes successfully. If supplied, a RadiusKey goes to the PTKSTART state;
otherwise, it goes to the DISCONNECTED state.
INITPSK: This state is entered when a pre-shared key is configured.
PTKSTART: This state is entered from INITPMK or INITPSK to start the 4-way
handshake, or if no response to the 4-way handshake occurs.
PTKINITNEGOTIATING: This state is entered when the second EAPOL-Key

message for the 4-way handshake is received with the key type of Pairwise key.
PTKINITDONE: This state is entered when the last EAPOL-Key message for the 4-
way handshake is received with the key type of Pairwise key. This state may call
SetPTK. If this call fails, the AP shall detect and recover from the situation (for
example, by performing a Disconnect event for this association).
UPDATEKEYS: This state is entered when an EAPOL-Key message is received

from the Supplicant to initiate the 4-way handshake from the Supplicant. The key
type in the EAPOL-Key message must be set to Pairwise key, and the Request bit
must be set.
INTEGRITYFAILURE: This state is entered when a data integrity failure occurs either
locally or from a remote station by receiving an EAPOL-Key message with the key
type set to Pairwise key. The Request and Error bits must be set.

KEYUPDATE: This state is entered from INTEGRITYFAILURE.
REKEYNEGOTIATING: This state is entered when the Group key is to be sent to the
Supplicant.
Note: The TxRx flag for sending a Group Key is always the opposite of whether the Pairwise Key is
used for data encryption/integrity. If a Pairwise key is used for encryption/integrity, then the station
never transmits with the Group Key; otherwise, the station uses the Group Key for transmit.
REKEYESTABLISHED: This state is entered when an EAPOL-Key message is

received from the supplicant with the key type set to Group key.
KEYERROR: This state is entered if the EAPOL-Key acknowledgement for the

Group key update is not received.
SETKEYS: This state is entered if the Group key is to be updated on all Supplicants.
SETKEYSDONE: This state is entered if the Group key has been updated on all
Supplicants.
(Note: SETKEYSDONE calls SetGTK to set the Group key for all associated
stations. If this fails, all communication via this key will fail, and the AP must detect
and recover from this situation.)
Informative Note: SETKEYSDONE calls SetGTK to set the Group key for all associated stations if
this fails all communication via this key will fail and the AP needs to detect and recover from this
situation.
8.5.7.2 Authenticator state machine variables

AuthenticationRequest – This variable is set TRUE if the STA’s IEEE 802.11
Management Entity wants a BSSID to be authenticated. This can be set when the
STA associates or at other times.
ReAuthenticationRequest – This variable is set TRUE if the IEEE 802.1X

Authenticator received an eapStart or 802.1X::reAuthenticate is set.
DeauthenticationRequest – This variable is set TRUE if a disassociation or

Deauthentication message is received.
RadiusKeyAvailable – This variable is True is a Radius key was supplied.
EAPOLKeyReceived – This variable is set TRUE when an EAPOL-Key message is

received. EAPOL-Key messages that are received in respond to an EAPOL-Key
message sent by the Authenticator must contain the same Replay Counter as the
Replay Counter in the transmitted message. EAPOL-Key messages that contain
different Replay Counters should be discarded. An EAPOL-Key message that is sent
by the Supplicant in response to an EAPOL-Key message from the Authenticator
must not have the Ack bit set. EAPOL-Key messages sent by the Supplicant not in
response to an EAPOL-Key message from the Authenticator must have the Request
bit set.

25
APs encryption/integrity engine with the new key.
Disconnect
DISCONNECT
DeauthenticationRequest STADisconnect()
UCT
DISCONNECTED AUTHENICATION
GNoStations-- GNoStations++
PTK = 0;
Init 802.1X::portControl = Auto;
UCT 802.1X::portMode = Enabled;
ReAuthenticationRequest
INITIALIZE UCT
MSK = 0
GInitAKeys = PInitAKeys = IntegrityFailed = False AUTHENICATION2
If Unicast cipher supported by Authenticator
Pair = 1 ANonce = Counter++;
Remove PTK
802.1X:portSecure = 0
802.1X::authSuccess
PSK
INITPMK INITPSK
PMK = RadiusKey PMK = PSK
!RadiusKeyAvailable
GUpdateStationKeys
|| (GKeyReady && PInitAKeys) UCT
TimeoutEvt
TimeoutCtr>N RadiusKeyAvailable
REKEYNEGOTIATING
TimeoutEvt
PInitAKeys = False
GUpdateStationKeys = False
Send EAPOL(1, 1, 1, !Pair, GN, G, GNonce, MIC(PTK), GTK[GN]); PTK START
TimeOutCtr++ Send EAPOL(0, 0 ,1 , 0, 0, P, ANonce, 0, 0)
TimeOutCtr++
EAPOLKeyRecieved
&& K == Group EAPOLKeyRecvd
TimeoutCtr>N && MICVerified && K == Pairwise
REKEYESTABLISHED TimeoutEvt && MICVerified
KEYERROR Check MIC(PTK)
GKeyDoneStations--
GKeyDoneStations–- PTKINITNEGOTIATING
TimeOutCtr = 0 PTK = Calc PTK(ANonce, SNonce)
802.1X::portSecure = 1 Check MIC(PTK)
Send EAPOL(0, 1, 1, Pair, 0, P, ANonce, MIC(PTK), 0)
GTKAuthenticator &&
UCT (GTKReKey EAPOLKeyRecvd
|| (GInitAKeys && !GInitDone)) && K == Pairwise
TimeoutCtr>N
&& MICVerified
SETKEYS PTKINITDONE
GTKReKey = False
If GInitDone == False { Check MIC(PTK)
GTK[0..N] = 0; If Pair == 1
GN = 1 Set PTK(0, Tx/RX, PTK)
GM = 2 GInitAKeys = True
} PInitAKeys = True
Else
Swap(GM,GN) EAPOLKeyRecvd &&
GInitDone = True Request == True
GKeyDoneStations = GNoStations && MICVerified
GNonce = Counter++;
GTK[GN] = Calc GTK(GNonce); UPDATEKEYS
GUpdateStationKeys = True Check MIC(PTK)
GKeyDoneStations == 0 IntegrityFailed
IntegrityFailed
(Error == True)
SETKEYSDONE !IntegrityFailed
SetGTK(GN, Tx/Rx, GTK[GN]) (Error == False)
GKeyReady = True INTEGRITYFAILURE
IntegrityFailed = False UCT
If Group Key failure
GTKReKey = True
Waitupto60()
UCT
KEYUPDATE
ANonce = Counter++;
GNonce = Counter++;
UCT
Figure 3—Authenticator State Machine
26
available to be sent to Supplicants.
GNoStations – This variable counts the number of Authenticators so it is known how

many Supplicants need to be sent the Group key.
GKeyReady – This variable is set to TRUE when a Group key has been sent to all
current Supplicants. This is used by new Authenticator state machines to decide
whether a Group key is available to immediately send to its Supplicant.
PInitAKeys – This variable is set to TRUE when the Authenticator is ready to send a
Group key to its Supplicant after initialization.
Counter – This variable is the global station Key Counter used for generating
Nonces.
ANonce – This variable holds the current Nonce to be used if the station is an
Authenticator.
GNonce – This variable holds the current Nonce to be used if the station is a Group
key Authenticator.
GN, GM – These are the current key indexes for Group keys. Swap(GM, GN) means
that the global key index in GN is swapped with the global key index in GM, so now
GM and GN are reversed.
PTK – This variable is the current Pairwise transient key.
GTK[] – This variable is the current Group transient keys for each Group key index.
PMK – PMK is the buffer holding the current Pairwise Master Key.
802.1X::XXX – the IEEE 802.1X state variable XXX.
8.5.7.3 Authenticator state machine procedures

STADisconnect() – Execution of this procedure disassociates and deauthenticates
the station.
CalcGTK(x). – Calculates the Group Transient Key(GTK) using GNonce as the

nonce input to the PRF.
RemoveGTK(x)/Remove PTK – Deletes GTK or PTK from encryption/integrity

engine.
MIC(x) – Computes a Message Integrity Code over the plaintext data.
CheckMIC(). – Verifies the MIC computed by MIC() function.
Waitupto60() – This procedure should stop the Authenticator state machines for all
stations at this point if the state machines enter this procedure until 60 seconds have
gone by from the last exit from this procedure; i.e. the first time this state machine is
27
entered, it can return immediately. The next time it must stop here until at least 60
seconds from the last time someone has left has gone by. If multiple state machines
enter this procedure at the same time then 60 seconds must go by for each state
machine to leave this procedure.
2.2.5.4.10.1 Station State Diagram

Station state diagrams for WPA are provided in Wi-Fi WPA Clauses 8.5.6. and 8.5.6.1.
2.2.5.5 Sample Key Exchanges

This section gives the following samples of key exchanges using the state diagrams in the
previous section:
1. Initialization of keys
This occurs whenever a Supplicant authenticates to an Authenticator.
2. Updating the Group key
This occurs on a management event, when the current Group key must be
changed. When this event occurs will depend on the environment of the network.
Possible times are:
1. Whenever a supplicant disassociates from an Authenticator, so that no
supplicant can decrypt any traffic after leaving the network. This is especially
important for networks that do not use the Pairwise key for unicast traffic
protection.
2. Several times a day to reduce leakage of information without taking the
overhead of updating the Group key at every logoff.
2.2.5.5.1 Group Key Update

A sample group key distribution is shown in Clause 8.5.4.4.
2.2.5.6 Temporal Keys Processing Rules

The processing rules for temporal keys are specified in Clause 8.7. The pseudo-code for
temporal key processing is defined in Subclauses 8.7.2.1 through 8.7.2.4.
2.2.5.7 Pseudo-Random Function

The pseudo-random function (PRF) capabilities for WPA are described in Annex H.3 of
IEEE P802.11i.
(Note: When used to generate key material, the PRF shall never be used with the same
input parameters. Note the use of the Global Counter for generating unique nonces. The
reason is that outputs from shorter PRFs, are prefixes of longer PRFs, given the same
input.)

28
2.3 ASCII Password Support for Pre-Shared Key
WPA uses the password hash function described in Annex H.4 of IEEE P802.11i to
define the algorithm to generate the 256bit key used in pre-shared key authentication.
It is recommended that users enter passwords longer than 8 characters (e.g., 20 characters
or longer).

3 Temporal Key Integrity Protocol
WPA uses the Temporal Key Integrity Protocol (TKIP) for data privacy. TKIP is
described in Clause 8.3.2 (including subclauses). The following changes shall be made to
the text:
(Note: TKIP Replay protection rules means that certain features that re-order packets will
not work:
1. Use of Contention Free without wireless multimedia extensions (WME) or
802.11e will not work.
2. Use of Power Save with Group key only will not work unless encryption and
integrity protection is done after re-ordering of multicast/unicast packets.
3. Use of quality of service (QoS) without WME or 802.11e will not work unless
encryption and integrity protection is done after any packet re-ordering.)
3.1 Active Countermeasures

MIC countermeasures are as described in Clause 8.3.2.3.2, except that upon a subsequent
MIC failure within 60 seconds, the behavior is as follows:
When a subsequent MIC failure occurs within 60 seconds of the preceding failure, then a
device will disassociate itself (if a Supplicant) or disassociate all associated STAs (if an
Authenticator). Furthermore, the device will not deliver any class 3 TKIP encrypted data
frames to or from any peer for a period of 60 seconds. If the device is an AP, it shall
disallow new associations for a period of 60 seconds; at the end of the 60-second period,
the AP shall resume normal operations and allow STAs to (re)associate. If the device is a
Supplicant, it shall first send a Michael MIC failure report frame prior to revoking its
PTK and disassociation.
The countermeasures used by an Authenticator are depicted in Figure 4 and described as
follows:
• For an Authenticator that detects a Michael MIC failure event:
1. Increment the MIC failure counter.
2. If this is the first MIC failure, initialize the countermeasures timer. If the
failure was in a unicast frame, discard the offending frame.
3. If less than 60 seconds have passed since a previous Michael MIC failure,
transition every STA using TKIP (for either unicast or broadcast/multicast
frames) in the BSS to State 2 in the 802.11 state diagram. This effectively
disassociates and deletes the PTK for all the STAs. The group temporal key
(GTK) must also be revoked. The Authenticator shall disallow associations
using TKIP for the duration of 60 seconds. At the end of the 60 seconds, the
MIC failure counter and timer may be reset, and new associations resume.
4. If the Authenticator is using EAP, transition the state of the Authenticator
state machine to State INITIALIZE. This will restart the EAP state machine.
If the Authenticator is using PSKs, this step is omitted.
5. Log details of the Michael MIC failure.
Michael MIC
Failure Event
Received
Timer < 60 No Timer = 0 Continue
Yes
Disassociate all
STAs, Revoke all
PTKs and GTK
Wait 60 Seconds Plumb new GTK,

before allowing Enable Continue
TKIP associations associations
Figure 4—Authenticator Countermeasures
(Note: While a Supplicant may disassociate with a reason code of Michael MIC failure,
the Authenticator shall not log the disassociation as a Michael MIC failure event; this is
to prevent denial of service attacks through disassociations. The Supplicant must report
the Michael MIC failure event through the Michael MIC failure report frame in order for
the AP to log the event.)
(Note: Because an access point may support ciphers other than TKIP, the Authenticator
may disassociate all STAs who are using TKIP while allowing non-TKIP running STAs
to remain associated.)
(Note: It is an implementation decision whether an AP will continue to transmit
Beacons and Probe Responses during the lockout period, and whether those frames
will indicate support for TKIP.)
(Note: The requirement to disassociate all stations using TKIP will include those
using AES as a pairwise cipher if they are also using TKIP as the group cipher.)
(Note: Because a single multicast frame can trigger multiple Michael MIC Failure
reports, preventing this single frame from forcing a disassociation at the access point,
the EAPOL MIC Failure report can provide the TSC value detected in the multicast
frame in the EAPOL-Key RSC field. The access point can discard subsequent
EAPOL MIC Failure reports if the RSC fields are the same.)
The countermeasures used by a Supplicant is depicted in Figure 5 and described as
follows:

• For a Supplicant that detects a MIC failure event due to a unicast or multicast
Michael MIC failure:
Michael MIC Failure

Event from a received
frame
Send Michael MIC

Failure Report
frame
Timer < 60 No Timer = 0 Continue
Yes
Stop Receiving Class 3 frames

Ensure Michael MIC Failure Report frame was sent
Disassociate from AP
Wait 60 seconds
before associating Continue
with TKIP
Figure 5—Supplicant Countermeasures
1. Increment the MIC failure counter.

2. Send a Michael MIC failure report frame to the AP.
3. If this is the first MIC failure, initialize the countermeasures timer.
Discard the offending frame.
4. If less than 60 seconds have passed since a previous Michael MIC failure,
delete the PTK (and GTK). Disassociate from the AP, and wait for 60
seconds before (re)establishing a TKIP association with any AP.
• If a non-AP STA receives a Disassociation frame with Reason Code Michael MIC
Failure, it can not be certain that the frame has not been forged, because it does not
contain a MIC. The STA may attempt association with this or another AP. If the
frame was genuine, then attempts to associate with the same AP requesting the use
of TKIP will probably fail, because the AP will be conducting countermeasures.

3.1.1 10.3.19 Michael MIC Failure Event
3.1.2 10.3.19.1 MLME-MichaelMICFailure.indication
3.1.3 10.3.19.1.1 Function

This primitive reports that a Michael MIC Failure event was detected.
3.1.4 10.3.19.1.2 Semantics of the Service Primitive

The primitive parameters are as follows:
MLME-MichaelMICFailure.indication {
Count
}
See Table 2.
Table 2—Michael MIC Failure Data
Name Type Valid Description

Range
Count Integer 1 or 2 The current number of Michael MIC failure
event
3.1.5 10.3.19.1.3 When Generated

This primitive is generated by the MAC when it has detected a Michael MIC
failure.
3.1.6 10.3.19.1.4 Effect of Receipt

The SME is notified that the MAC has detected a Michael MIC failure.
3.1.7 10.3.20 EAPOL (Michael MIC Failure Report)
3.1.8 10.3.20.1 MLME-EAPOL.request
3.1.9 10.3.20.1.1 Function

This primitive indicates that this EAPOL message shall be confirmed.
3.1.10 10.3.20.1.2 Semantics of the Service Primitive

The primitive parameters are as follows:
MLME-EAPOL.request {
Source address,
Destination address,
Data
}
See Table 3.
Table 3—MLME-EAPOL Data
Name Type Valid Description

Range
Source Address MAC address N/A The MAC sublayer address to which the
EAPOL frame is being transferred
Destination MAC address N/A Either an individual or group MAC
Address sublayer entity address t
Data IEEE 802.1X N/A The EAPOL frame to be transmitted
EAPOL Key
frame
10.3.20.1.3 When Generated

This primitive is generated by the station management entity (SME) when an
EAPOL message has been acknowledged.

The MAC is notified that this EAPOL frame must be ACKed.
3.1.12 10.3.20.2 MLME-EAPOL.confirm
3.1.13 10.3.20.2.1 Function

This primitive indicates that this EAPOL frame has been ACKed by IEEE
802.11.
3.1.14 10.3.20.2.2 Semantics of the service primitive

There are no parameters for this primitive.

10.3.20.2.3 When Generated
This primitive is generated by the MAC when an EAPOL frame has been
ACKed.

The SME is notified that this EAPOL frame has been IEEE 802.11 ACKed.
3.2 Multicast/Broadcast Data Packets to AP

An AP shall drop any data multicast/broadcast MSDU packets it receives from stations.
WPA does not provide security for broadcast/multicast frames sent from non-AP STAs.
3.3 TKIP and Michael Implementation Checklist

Carrying out the following checklist has been found to be useful in validating the TKIP
and Michael implementations:
1. The TKIP and MIC engines are verified against the test vectors.
2. The MIC is calculated on the MSDU and not the MPDU fragments.
3. The two addresses that are MICed with the data portion of the MSDU are
destination address (DA) and source address (SA), the ultimate destination and
source of the packet, and not the transmitter address (TA) and receiver address
(RA). (Note: The DA and SA are in different positions of the 802.11 header,
depending on whether sent to or from the AP.)
4. The MIC key used on the Client for transmit (TX) is in bytes 24–31, and the MIC
key used on the Client for receive (RX) is in bytes 16–23 of the PTK.
That is, assume that TX MIC and RX MIC referred to in Clause 8.7 are
referenced to the Authenticator. Similarly, on the AP, the MIC used for TX is in
bytes 16–23, and the MIC key used for RX is in bytes 24–31 of the PTK.
5. The MSDU is padded with a byte of 0x5a and then from 4 to 7 0x00s before
calculating the MIC on TX. (Variable padding ensures that MIC is calculated on
a multiple of 4-byte words.)
6. The pad bytes in 5. are not transmitted with the packet. That is, the 8 byte MIC is
inserted after the last byte of the original payload.
7. On RX, a pad byte of 0x5a and from 4–7 bytes of 0x00 is inserted between the
last byte of data and the MIC, and included in the MIC calculation. The MIC
itself in the RX frame is not part of the MIC calculation but is compared to the
MIC calc output.
8. The pad bytes inserted in the packet on RX are not sent up to Windows with the
packet.
9. The TKIP Phase 1 calculation uses the Transmitter Address. A client uses its own
address for TX P1k and the AP's Address for RX P1K.
10. The Phase 1 key is initialized when receiving the Add Key from NDIS. That is,
initializing the TSC to 0's, then the P1K must be run on the 0's TSC before the
key is used to generate a per-packet key. This applies independently to both RX
and TX directions.
11. The IV inserted into the TX Packet conforms to the coding described in the WPA
document. That is, the first three bytes of IV are from the first three bytes of the
per packet Phase 2 key, the next byte includes the key id and the ext IV bit set,
and the next four bytes contain the upper four bytes of the TSC.
12. On the AP the pairwise key assigned to a Client shall have a key id of 0. Group
Keys created by the AP shall have a key ID of 1, 2 or 3.

4 Layer Management Updates
WPA updates the layer management of the original IEEE 802.11 1999 Standard per the
following clauses:
• 10.3.2.2.2
• 10.3.6.1.2
• 10.3.6.3.2
• 10.3.7.1.2
• 10.3.7.3.2
• 10.3.17 (including all subsections)
• 10.3.18 (including all subsections)
• 10.3.19
• 10.3.20
• 10.3.22
• 10.3.23.
STAKey-related primitives are not supported in WPA.
5 MAC Sublayer Management Updates

WPA updates the sublayer management of the original IEEE 802.11 1999 Standard per
the following clauses:
• 11.3 (including all subsections)
• 11.4 (including all subsections).

Appendix A: TKIP Algorithm Reference Implementations
and Test Vectors
A TKIP reference implementation and test vectors are provided in Annex H.1 and
subclauses of IEEE P802.11i.
Appendix B: Michael Reference Implementation and Test

Vectors
A Michael reference implementation and test vectors are provided in Annex H.2 and
subclauses of IEEE P802.11i.
Appendix C: WPA Information Element Reference

Implementation
#include "stdafx.h"
#include <stdio.h>
#define uchar unsigned char

#define ushort unsigned short
#define NONE -1
#define WEP40 0
#define TKIP 1
#define AESCCMP 2
#define RESERVED 3
#define WEP104 4
#define IEEE802_1X 0
#define ELEMENTID 0xdd
#define GROUPFLAG 0x02
#define REPLAYBITSSHIFT 2
#define REPLAYBITS 0x03
struct _IE {
uchar Elementid;
uchar length;
uchar oui[4];
ushort version;
uchar multicast[4];

ushort ucount;
struct {
uchar oui[4];
} unicast[1]; // the rest is variable so need to
// overlay ieauth structure
};
struct _ieauth {
ushort acount;
struct {
uchar oui[4];
} auth[1];
};
int multicast;
int unicast[4];
ushort ucount;
int auth[4];
ushort acount;
int unicastasgroup;
int replayindex;
void test(struct _IE *IE, int length)

{
uchar oui00[4] = { 0x00, 0x50, 0xf2, 0x00 };
uchar oui01[4] = { 0x00, 0x50, 0xf2, 0x01 };
uchar oui02[4] = { 0x00, 0x50, 0xf2, 0x02 };
uchar oui03[4] = { 0x00, 0x50, 0xf2, 0x03 };
uchar oui04[4] = { 0x00, 0x50, 0xf2, 0x04 };
uchar oui05[4] = { 0x00, 0x50, 0xf2, 0x05 };
int i = 0, j, m, n;
struct _ieauth *ieauth;
char *caps;
multicast = TKIP;
unicast[0] = TKIP;
ucount = 1;

auth[0] = IEEE802_1X;
acount = 1;
unicastasgroup = 0;
replayindex = 2;
// information element header makes sense

if ( (IE->length+2 == length) && (IE->length >= 6)
&& (IE->Elementid == ELEMENTID)
&& !memcmp(IE->oui, oui01, 4) && (IE->version == 1)) {
// update each variable if IE is long enough to contain the
// variable
if (IE->length >= 10) {
if (!memcmp(IE->multicast, oui01, 4))
multicast = WEP40;
else if (!memcmp(IE->multicast, oui02, 4))
multicast = TKIP;
multicast = AESCCMP;
multicast = WEP104;
else
// any vendor checks here
multicast = -1;
}
if (IE->length >= 12) {
j = 0;
for(i = 0; (i < IE->ucount)
&& (j < sizeof(unicast)/sizeof(int)); i++) {
if(IE->length >= 12+i*4+4) {
if (!memcmp(IE->unicast[i].oui, oui00,
4))
unicast[j++] = NONE;
else if (!memcmp(IE->unicast[i].oui,
oui02, 4))
unicast[j++] = TKIP;
else if (!memcmp(IE->unicast[i].oui,
oui03, 4))
unicast[j++] = AESCCMP;

else
;
}
else
break;
}
ucount = j;
}
m = i;
if (IE->length >= 14+m*4) {
// overlay ieauth structure into correct place
ieauth = (struct _ieauth *)IE->unicast[m].oui;
j = 0;
for(i = 0; (i < ieauth->acount)
&& (j < sizeof(auth)/sizeof(int)); i++) {
if(IE->length >= 14+4+(m+i)*4) {
if (!memcmp(ieauth->auth[i].oui, oui00,
4))
auth[j++] = IEEE802_1X;
else
;
}
else
break;
}
if(j > 0)
acount = j;
}
n = i;
if(IE->length+2 >= 14+4+(m+n)*4) {
caps = (char *)ieauth->auth[n].oui;
unicastasgroup = (*caps)&GROUPFLAG;
replayindex =
2<<((*caps>>REPLAYBITSSHIFT)&REPLAYBITS);
}
}

}
char *cip[] = { "", " WEP40", " TKIP", " AES-CCMP", “WEP104” };
char *cip1[] = { " NONE", " WEP40", " TKIP", " AES-CCMP", “WEP104” };
char *aip[] = { "", " 802.1X" };
// Various IEs to try above with

uchar test1[] = { 0xdd, 0x06, 0x00, 0x50, 0xf2, 0x01, 0x01, 0x00 };
uchar test2[] = { 0xdd, 0x0a, 0x00, 0x50, 0xf2, 0x01, 0x01, 0x00,
0x00, 0x50, 0xf2, 0x01};
uchar test3[] = { 0xdd, 0x10, 0x00, 0x50, 0xf2, 0x01, 0x01, 0x00,
0x00, 0x50, 0xf2, 0x01,
0x01, 0x00, 0x00, 0x50, 0xf2, 0x00};
0x00, 0x50, 0xf2, 0x01,
0x01, 0x00, 0x00, 0x50, 0xf2, 0x02 };
0x00, 0x50, 0xf2, 0x01,
0x01, 0x00, 0x00, 0x50, 0xf2, 0x02,
0x01, 0x00, 0x00, 0x50, 0xf2, 0x00,
0x06, 0x00 };
uchar test6[] = { 0xdd, 0x1c, 0x00, 0x50, 0xf2, 0x01, 0x01, 0x00,
0x00, 0x50, 0xf2, 0x02,
0x02, 0x00, 0x00, 0x50, 0xf2, 0x02, 0x00, 0x50, 0xf2, 0x03,
0x01, 0x00, 0x00, 0x50, 0xf2, 0x00,
0x02, 0x00 };
// too small - ignored
uchar test7[] = { 0xdd, 0x04, 0x00, 0x50, 0xf2, 0x01, 0x01, 0x00 };
// unicast count too high, 2nd unicast ignored and default auth
0x00, 0x50, 0xf2, 0x01,
0x02, 0x00, 0x00, 0x50, 0xf2, 0x02,
0x01, 0x00, 0x00, 0x50, 0xf2, 0x00};
// unicast count past end of IE
0x00, 0x50, 0xf2, 0x01,
0x10, 0x00, 0x00, 0x50, 0xf2, 0x02,

0x01, 0x00, 0x00, 0x50, 0xf2, 0x00};
uchar *tests[] = { test1, test2, test3, test4, test5, test6, test7,

test8, test9, NULL };
int testsize[] = { sizeof(test1), sizeof(test2), sizeof(test3),
sizeof(test4), sizeof(test5), sizeof(test6), sizeof(test7),
sizeof(test8), sizeof(test9), 0 };
int _tmain(int argc, _TCHAR* argv[])

{
for(int i = 0; tests[i] != NULL; i++) {
test(( struct _IE *)tests[i], testsize[i]);
printf("IE %d Multicast%s Unicast%s%s%s%s Auth%s%s%s%s
%sReplayIndex %d\n",
i, cip1[(multicast+1)], cip1[(ucount>0?unicast[0]:-
1)+1],
cip[(ucount>1?unicast[1]:-1)+1],
cip[(ucount>2?unicast[2]:-1)+1], cip[(ucount>3?unicast[3]:-1)+1],
aip[(acount>0?auth[0]:-1)+1], aip[(acount>1?auth[1]:-
1)+1], aip[(acount>2?auth[2]:-1)+1], aip[(acount>3?auth[3]:-1)+1],
unicastasgroup?"Group ":"", replayindex);
}
return 0;
}
Appendix D: ASCII Password Reference

A reference implementation for ASCII password support is provided in Annex H.4 and
subclauses of IEEE P802.11i with the following changes.
The first call to hmac-sha1 in the reference code should read
hmac_sha1(
digest, ssidlength+4,
(unsigned char *)password, (int)strlen(password),
digest1);

Appendix E: IEEE 802.1X State Synchronization
This document assumes the synchronization variables defined in IEEE 802.1X-REV.
Appendix F: Michael Countermeasures State Machines
This appendix describes the state machines for the TKIP Michael MIC Countermeasures.
These state machines are an extension for existing state machines, not a replacement. For
example, data frames from disassociated stations are discarded in the existing state
machines, so that there is no need to repeat it in this description. See Figures 6 through
11.
Client STA AP “Higher

“Higher Layer Layer
Software” Software”
CLIENT STA AP MAC

MAC
Figure 6—System Structure

Figure 7—Client STA MAC, Part 1

Blocking
MLME- MLME- MA-

EAPOL.request MLME- Received data
DISASSOCIATE UNITDATA.req
ASSOCIATE frame
.request uest
.request
‘Carry out
Send frame disassociation’
MLME-
Blocking
ASSOCIATE
.confirm(Michael
MLME- MLME-
failure)
EAPOL.con DISASSOCI
firm ATE.confirm
Note that this is
rejecting the
association
Blocking Blocking
Yes
BlockingTimeout Waiting For

Dissassociation
Still MLME-
Associated? DISASSOCIATE
.request
No
‘Carry out
disassociation’
State 2
MLME-
DISASSOCI
ATE.confirm
State 2
Figure 8—Client STA MAC, Part 2

46
Figure 9—Client STA Higher Layer Software

Normal
Operation
MLME-
Frame with
MichaelMICFailure.
MIC failure
request
detectTimer
running &&
Yes No
less than
60?
‘Start the
‘Disassociate all
detectTimer’
STAs. All RX & TX
data should be
dropped’
Normal
Operation
‘Start 60 second
blocking timeout’
Blocking
Association
MA-
Request Blocking
MichaelMICFailure.
Frame from timeout expired
request
STA
Note that all STAs
are disassociated,
Disassociation Normal Operation so all data traffic
frame (MIC will be dropped
failure) to STA
Blocking
Figure 10—AP MAC

Figure 11—AP Higher Layer Software

Appendix G: WPA Requirements
Function Required/Recommended/Optional
48bit TKIP (including phase 1 and 2) Required
Fragmentation of TKIP data packets Optional
(Note: The station will not be able to send full-
size 802.11 MPDUs if fragmentation is not
supported.)
Defragmentation of TKIP data packets Required
Use of integrity check and IV for replay Required
protection
Michael Required
Michael counter measures Required
WPA information element in beacon, probe Required
response, association/re-association request
Privacy bit set in capability information element Required
Beacon/Probe response/association/re-association
request
4-way handshake Required
Validation of WPA IE in beacon/probe Required
response/association/re-association request with
WPA IE in 4-way handshake
Group key update Required
Pairwise Request (with or without error) Required
Group Request (with or without error) Required
Encryption of 802.1X messages with Pairwise Required
key
802.1X messages not encrypted with Group Keys Required
WPA authentication mode Required
WPA-PSK authentication mode Required
WPA-None authentication mode Optional for NIC
Open 802.11 MAC authentication for all WPA Required
authentication modes
WPA-PSK ASCII passphrase hash Required
WPA-PSK 256 bit key Recommended

Function Required/Recommended/Optional
Non-WPA support Recommended
Non-WPA and WPA mixed mode Recommended
Group key cipher Required
Pairwise key cipher Required for NIC
Recommended for AP
No sending of non-802.1X data packets until the Required
correct key is installed. (Note: This is Group key
for multicast/broadcast from AP or from station
if Pairwise key is not installed. This is Pairwise
key for unicast from AP or all traffic from station
if a Pairwise key is installed.)
Queuing of EAPOL-Key messages when in Required
power save
Saving of IBSS IV Required
Support for RADIUS Required for AP (WPA-Enterprise)
Optional for AP (WPA-Personal)
Group Key Update on a time interval Recommended
Group key update on a disassociation of a Optional
authenticated station
Use of PRF for Pairwise key generation Required
Use of PRF for Group Key generation Required
Use of random number on AP for master key for Required
Group Key generation
Initialization of Key Counter Required
Initialization of EAPOL-IV from Key Counter Required
Appendix H: Suggestions for Random Number

Generation
Annex H.5 and subclauses of IEEE P802.11i address suggestions for random number
generation.

51

WPA 80211 v3 1 090922

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WPA 80211 v3 1 090922

Uploaded by

Copyright:

Available Formats

Wi-Fi Protected Access

WI-FI ALLIANCE PROPRIETARY – SUBJECT TO CHANGE WITHOUT NOTICE

Version 3.1 – August 2004

WI-FI PROTECTED ACCESS (WPA) .................................................................. I

2 WPA OVERVIEW .........................................................................................5

2.2 Authentication and Association Overview............................................................................ 9

2.3 ASCII Password Support for Pre-Shared Key................................................................... 29

3 TEMPORAL KEY INTEGRITY PROTOCOL ..............................................30

3.2 Multicast/Broadcast Data Packets to AP ............................................................................ 35

3.3 TKIP and Michael Implementation Checklist.................................................................... 35

4 LAYER MANAGEMENT UPDATES...........................................................37

5 MAC SUBLAYER MANAGEMENT UPDATES ..........................................37

APPENDIX A: TKIP ALGORITHM REFERENCE IMPLEMENTATIONS AND

APPENDIX B: MICHAEL REFERENCE IMPLEMENTATION AND TEST

APPENDIX C: WPA INFORMATION ELEMENT REFERENCE

APPENDIX D: ASCII PASSWORD REFERENCE .............................................43

APPENDIX E: IEEE 802.1X STATE SYNCHRONIZATION ...............................44

APPENDIX F: MICHAEL COUNTERMEASURES STATE MACHINES ............44

APPENDIX G: WPA REQUIREMENTS .............................................................50

Version 3.1 – August 2004 ii

Version 3.1 – August 2004 iii

Version 3.1 – August 2004 1

1.1 Abbreviations and Acronyms

Version 3.1 – August 2004 2

Version 3.1 – August 2004 3

Version 3.1 – August 2004 4

Version 3.1 – August 2004 6

Table 1—Configuration Options and Expected System Behavior

Network Authentication Mode Encryption Manual Key 802.1X

2.1 Advertisement of WPA Availability

Version 3.1 – August 2004 8

2.2 Authentication and Association Overview

Version 3.1 – August 2004 9

Version 3.1 – August 2004 10

2.2.2 Encrypted/Unencrypted Data Handling

2.2.3 Authentication and Key Management Overview

2.2.3.1 Mandatory Authentication and Key Management

2.2.3.2 Optional IBSS Global Pre-Shared Key System

Figure 1—Global Pre-Shared State Machine

Version 3.1 – August 2004 12

2.2.4 EAPOL-Key Frames

Version 3.1 – August 2004 13

2.2.5 802.1X Authentication

2.2.5.1 Key Hierarchy

2.2.5.2 Mapping EAPOL Keys to 802.11 Keys

2.2.5.3 Nonce Generation

Version 3.1 – August 2004 14

2.2.5.4.2 4-Way Handshake

2.2.5.4.3 Group Key Update

2.2.5.4.5 Use of the Secure Bit

2.2.5.4.6 Use of the EAPOL-Key Replay Counter

2.2.5.4.7 Use of the EAPOL-Key Key Data for Pairwise Keys

2.2.5.4.8 EAPOL-Key Encoding

2.2.5.4.9 4-Way Handshake

2.2.5.4.10 State Diagrams

8.5.6 Supplicant key management state machine

Version 3.1 – August 2004 16

Figure 2—Supplicant Key Management State Machine

UCT means the event triggers an immediate transition.

The Management entity will send an AuthenticationRequest event when it wants an

8.5.6.1 Supplicant state machine states

AUTHENTICATION: A STA’s supplicant enters this state when it sends an IEEE