WPA WPA Eap Artikel Revised de Rev2

Wi-Fi Protected Access (WPA)
Abstract
This document captures those clauses of the IEEE 802.11i Draft
3.0 that comprise an enhanced security implementation for
802.11i known as Wi-Fi Protected Access. Implementation
notes are also provided.
Line number references to the 802.11i Draft 3.0 standard are used throughout
this document. In order to ensure consistent referencing, this document should
be used in conjunction with the Portable Document Format (PDF) version of the
IEEE 802.11i Draft 3.0 standard.
Version 2.0
April 29, 2003
Wi-Fi Alliance CONFIDENTIAL

Contents
1 INTRODUCTION 4
2 WPA OVERVIEW 5
2.1 Advertisement of WPA Availability 9
2.2 Authentication and Association Overview 10
2.3 ASCII Password Support for Pre-Shared Key 21
3 TEMPORAL KEY INTEGRITY PROTOCOL (TKIP) 21

3.1 Active Countermeasures 22
3.2 Multicast/Broadcast data packets to AP 30
3.3 TKIP and Michael implementation checklist 30
4 LAYER MANAGEMENT UPDATES 31
5 MAC SUBLAYER MANAGEMENT UPDATES 31
APPENDIX A: REMOVED 32
APPENDIX B: TKIP ALGORITHM REFERENCE IMPLEMENTATIONS AND

TEST VECTORS 32
APPENDIX C: MICHAEL REFERENCE IMPLEMENTATION AND TEST

VECTORS 32
APPENDIX D: WPA INFORMATION ELEMENT REFERENCE

IMPLEMENTATION 32
APPENDIX E: HMAC_MD5, HMAC_SHA1 AND PRF REFERENCE 37
APPENDIX F: ASCII PASSWORD REFERENCE 38
APPENDIX G: IEEE 802.1X STATE SYNCHRONIZATION 39
APPENDIX H: MICHAEL COUNTERMEASURES STATE MACHINES 39
APPENDIX I: WPA REQUIREMENTS 44
Wi-Fi Protected Access Version 2.0 – April 29, 2003 Wi-Fi Alliance CONFIDENTIAL
2
APPENDIX J: SUGGESTIONS FOR RANDOM NUMBER GENERATION 46
3
1 Introduction
Wi-Fi Protected Access (WPA) is a subset of 802.11i draft 3.0 that satisfies some of the
requirements of the full 802.11i standard. Some of the significant features of WPA are:
1. It supports two authenticated key management protocols in infrastructure mode
using 802.1X with pre-shared key and with EAP authentication. A simple IBSS
approach is described for reference but is not supported in WPA. The IBSS
approach described uses no authenticated key management protocol but uses a
pre-shared key directly as the encryption/integrity key (Note: IBSS is much
reduced in security since it has no key management).
2. 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 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 information element is described in Section 2.1 and Appendix D.
4. Authentication and Association are required
This is described in Section 2.2.
5. TKIP encryption with the Michael integrity check is required.
TKIP and Michael are described in Section 3.3.
6. It does not perform an integrity check on management and control messages.
7. It does not support preauthentication for fast handoff.
8. MIB support
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 256 bit key (since it is
used as the pairwise master key (PMK)) and the implementation will need
to be able to enter this value either as a 256bit key via hex or via an ASCII
password. It must be able to enter the key as 64 hex characters though it
may be possible to enter the key in a different format. If the key is entered
as an ASCII password the 256bit key must be generated as described in
Section 2.3.
A station should be able to configure a different pre-shared key for each
SSID.
4
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 256 bit key and the
implementation will need to be able to enter this value either as a 256bit
key via hex or via an ASCII password. It must be able to enter the key as
64 hex characters though it may be possible to enter the key in a different
format. 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 should 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.
2 WPA Overview
WPA supports the changes to the 1999 802.11 standard as described in the following
clauses of 802.11i Draft 3.0
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 of 802.11i
Draft 3.0
8.1
8.1.1 (TKIP only)
8.1.2
8.1.3
8.1.4
5
8.1.5
8.2 (including all subsections)
The following notes will be useful in the development of a WPA implementation.

APs advertise their capabilities in a WPA information element (IE). If the network
administrator doesn’t 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 non-WPA stations to associate or to not allow non-WPA
stations to associate. When configured to allow association of non-WPA stations, the
multicast cipher should be WEP.
The configuration options an AP should support are:
1. Select one or more station configurations to associate to the AP
a. WPA
b. WEP
c. WEP rekeying using the existing 802.1X EAPOL-key
message.
2. For WPA select the list of available ciphers for unicast
a. TKIP
b. AES
3. Pre-shared key for WPA which can be an ASCII passphrase or a 256
bit key
4. WEP key for static WEP stations which can be 40 or 104bits in length
The configuration options a station should support are:

1. Select the AP configurations the station will associate to
a. WPA
b. WEP
2. For WPA select the cipher to use for unicast
a. TKIP
b. AES
3. Pre-shared key for WPA which can be an ASCII passphrase or a 256
bit key
4. WEP key for static WEP stations which can be 40 or 104bits in length
The use of Pre-shared key is recommended for home use only, since the pre-shared key is
used as the PMK impersonation between stations or a station impersonating an AP is
possible.
6
The multicast cipher must always be the lowest unicast cipher enabled. So, 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. If only WPA is enabled in 1 and only AES is
enabled in 2, then the multicast cipher is AES.
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 the station is willing to communicate with, the station decides which APs it is
willing to use. The policy configuration could include the ciphers the station is willing to
use, the authenticated key management 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 should do 802.1X authentication and 802.1X key management. If the
authentication suite is WPA-PSK then it should 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
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 should have a way to disable non-WPA clients from associating.
If the AP supports WPA and non-WPA stations, there are a couple of cases to consider:
1. The non-WPA station supports an 802.1X supplicant that is a non-WPA 802.1X
supplicant. In this case the AP can use 802.1X to send WEP key updates to the
station. A non-WPA supplicant only supports group keys and so the AP must
track per station whether it supports unicast keys or not.
2. The non-WPA station does not support an 802.1X supplicant. Then the WEP key
must be pre-configured into the non-WPA station and AP. Since the AP for
broadcast/multicast traffic must use the pre-configured key, 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,
though 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 should be used to update the group key on non-WPA stations.
The station then associates with the AP using an association request message. The
association request message specifies the unicast and multicast ciphers it wants, given the
7
station’s cipher capabilities and configuration. When the station receives the association
response it authenticates using 802.1X with the AP. The AP sends an 802.11 association
response message (with Reason code 1) if it didn’t like something in the WPA
information element. When the AP receives the RADIUS accept, the AP then sends an
EAP-Success to complete the authentication at the station. The AP then does an EAPOL-
Key message exchange with the station to setup 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, when this document talks about sending an 802.11 disassociation and/or
802.11 deauthenticate message it means that the 802.11 MAC should send the necessary
messages to get the state between the source and destination stations to state 1 of 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 ESS mode otherwise it is WPA-None
For the case 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, that new station must use the
pre-configured key for broadcast/multicast. The AP can used 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 then a WPA
AP must use the “Unicast as Group key” WPA capability bit to decide whether to use
Pairwise keys as encryption/integrity keys or not.
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
should be a way to disable non-WPA clients from associating to the AP.
The following table describes the various configuration options and the expected system
behavior.
8
Network Authentication Encryption Manual 802.1X
Type mode or status Key enabled?
authenticated required?
key
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
Note: Manual Key required is whether a 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 the station has
chosen for its association. The beacon or probe response messages contain the
capabilities of an IBSS station.
WPA uses the RSN Information Element described in clause 7.3.2.17 with the following
changes
• The Element ID of page 19, line 10 shall be 221 instead of 48;
• An additional 4 octets is inserted before the Version field containing an OUI
and type fields of 00:50:F2:01.
9
• The OUI shall be 00:50:F2 instead of 00:00:00;
• WPA doesn't ignore WRAP and CCMP, it reserves the codes (per Table 2 of
page 20) but doesn't define the encryption schemes (See IEEE 802.11i Draft
3.0 for definitions of WRAP and CCMP);
• WPA has TKIP as default rather than CCMP;
• The preauthentication bit (p21, line14 and Figure 8) should 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 is allowed.
Note: “Authenticated Key Management using pre-shared key over 802.1X” means that
any STA that has the key can impersonate any other STA.
Note: If an AES cipher either WRAP or CCMP is used for unicast or for multicast then
the AES EAPOL-Key format key descriptor from 802.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 should 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. specifying a SSID
2. Find APs that are nearby for the selected SSID
3. Associate to a chosen APs
4. Initiate 802.1X authenticated key management
5. Install the 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 MLME-Scan.Request
3 is the management entity associating to a BSSID.
4 is the management entity initiating 802.1X authenticated key management by sending
an AuthenticationRequest to the Supplicant as described in Section 2.2.2.
5 is the management entity calling MLME-SetKeys.Request
Roaming can be done either by
1. (Re-)Associating and then doing 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
10
AP that the keys were obtained from. The station shall delete the keys when it
disassociates/deauthenticates from all BSSIDs in the ESS.
Connecting to an IBSS station consists of the following operations:
1. Select a network i.e. specifying a SSID
2. Find a WPA IBSS station that is nearby 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 should be applied:
1. A station must use IEEE 802.11 open authentication.
2. A station must complete 802.1X, obtain and install keys before attempting to send
class 3 data packets other than 802.1X
3. An AP must complete 802.1X, 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 a station.
6. If the AP fails during authentication, it sends a deauthenticate message.
7. An AP can delete a station’s state if it requires to because of inactivity timeout,
resource shortages, etc. This is 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 using Group keys.
Note: The use of Pairwise keys is more secure than the use of only Group keys,
since 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 message containing a Group key update to
a station, the AP may queue the message. If the AP deletes the message the AP
should 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, the station is asleep, etc.
11
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

Under normal circumstances the station and APs will either send 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 only allowed 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
A station on receiving a disassociate message or an 802.11 deauthenticate message
should delete the Pairwise key and attempt to rejoin the network (i.e. reassoicate 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 option 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 in 802.11i Draft 3.0.
5.1.1.4
5.1.1.5
5.2.2.2
5.4.2.2
5.4.2.3
5.4.2.4
5.4.3 and subclauses (References to TKIP only)
5.9 and subclauses
The security association management of WPA is described in the following clauses:
8.4.1. except for text relating to pre-authentication and IBSS
12
8.4.1.1
8.4.2
8.4.3
p79, line 8, text “STAs that fail to assert RSN” should read “… that fail to
include the RSNIE in the associate or re-associate request message”
p79, line 20 - Add a bullet “A STA must support a contiguous range of

versions.”
8.4.3.1
8.4.5
8.4.6 (excluding 8.4.6.1)
8.4.8
8.4.10, including subsections, with the following exception.
8.4.10.2 requires that a non-AP STA disassociate if it receives an encrypted unicast frame
when it does not have a key to decode the frame. A WPA compliant device may
optionally ignore the frame in question.
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
Wi-Fi Protected Access 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).
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.
PSK &&
!AuthenticationServerSystem
GLOBALPSK
Remove PTK
Remove GTK(1..2)
802.1X::portControl = ForceAuthorized;
GTK = PSK;
SetGTK(1, Tx/Rx, GTK);
802.1X:VirtualPort = True
802.1X::VirtualSecure = True
802.1X::portMode = Enabled;
Figure 1—Global Pre-shared State Machine
Note: When using TKIP the two MIC keys must be the same since there is no Supplicant
and Authenticator.
13
Note: A station when using pre-shared keys in IBSS mode must remember the last IV it
used with a particular pre-shared key and continue from that point when using the key
again.
Note: Saving the IV to non-volatile storage every N packets and when loading the IV out
of the non-volatile 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 48 bit value when a stored IV is not
available.
Note: While a different IV can be used for each pre-shared key, it is possible to share the
IV across the different pre-shared keys, so for example it is possible to store a single IV
for use with all the IBSS pre-shared keys. This reduces the information needed to be
stored in non-volatile storage at the expense of the time each pre-shared key can be used
for. Since the time for a single IV is over 800 years (or 100 years with N = 1,000,000)
sharing the IV doesn’t cause a problem.
Note: The station needs to track the receive IV for each station in range.
2.2.4 EAPOL-Key messages

WPA uses the EAPOL-Key messages of clause 8.5.2 of 802.11i Draft 3.0.
Note: There is an inconsistency in the reference to the bit descriptions in the key
information field in Draft 3.0. Bits 4 and beyond should be decremented by 1 for
consistency with Figure 49 of p. 92.
Note: The key descriptor type 1 should not be used when an AES cipher is used. See
802.11i Draft 3.0 for the key descriptor type to be used when an AES cipher is used.
2.2.5 802.1X authentication

WPA uses 802.1X as described in clause 5.9 of IEEE 802.11i Draft 3.0 to provide the
framework for AP/Station authentication.
2.2.5.1 Key hierarchy

WPA uses the TKIP and WEP encryption key hierarchies described in clause 8.5.1 and
it’s sub-clauses for pairwise keys and group keys.
Clause 8.5.1.1 should also show support for PRF-40 and PRF-104.
Clause 8.5.1.3 should also reference PRF-40, PRF-104 for support of WEP-40 and WEP-
104 as group keys in a transitional network with WEP clients.
2.2.5.2 Mapping EAPOL Keys to 802.11 Keys

WPA uses clause 8.6.1, clause 8.6.2, clause 8.6.7, and clause 8.6.8 to describe the
mapping of the pairwise and group transient keys to the TKIP and WEP encryption
protocols respectively.
14
2.2.5.3 Nonce Generation
WPA uses the nonce generation conventions defined in clause 8.5.7.
Note: A good source of a random number is required to initialize the Key Counter, if not
then 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, which is 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
messages is described in clause 8.5.2.1.
The following changes should be made to the text of 802.11i Draft 3.0:
Clause 8.5.3. – Line 33, p. 98; The key length is the length of the temporal key,
not necessarily 16 octets.
Clause 8.5.3.2 – Line 26, p. 99; The key length is 0.
Clause 8.5.3.3 – Line 22, p. 100; The key length is the length of the temporal key,
not necessarily 16 octets.
Clause 8.5.3.4 – Line 22, p. 101; The key length is 0.
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 should be made to the text of 802.11i Draft 3.0:
Clause 8.5.4.1 – line 38, p. 105; The key length is the length of the temporal key
and not necessarily 16 octets as shown.
Clause 8.5.4.2 – line 33, p. 106; The keyID is 0.
Clause 8.5.4.2 – line 41, p. 106; The Key Length is 0.
15
2.2.5.4.4 Supplicant Request for key update
The Supplicant can request for a key update by sending an EAPOL-Key message with the
Request bit set. This is used when the MAC detects a data integrity attack.
If the EAPOL-Key message 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 message 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 (see 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 this section.
2.2.5.4.5 Use of the secure bit

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 of the ACK bit and Replay Counter to make sure 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 must have the ACK bit set. Replays to a message
from the Authenticator must use the same replay counter value and he 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.
Example 4-way handshake
Message 1: MIC = 0, ACK = 1, Replay Counter = 0
Example 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.
16
2.2.5.4.8 EAPOL-Key encoding
This is addressed in clause 8.5.2.1 of the Draft
2.2.5.4.9 4-way Handshake

The 4-way handshake is decribed 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

2.2.5.4.10.1 Station state diagram
Station state diagrams for WPA are provided in clauses 8.5.5. and 8.5.5.1.
Line 22, p. 108 of Clause 8.5.5.1 should be changed from “to authenticate an SSID” to
“to authenticate a BSSID”
2.2.5.4.10.1.1 Supplicant state machine variables
The WPA supplicant state machine variables are described in clause 8.5.5.2.
2.2.5.4.10.1.2 Procedures
The WPA supplicant procedures are described in clause 8.5.5.3.
Line 9, p. 110 of clause 8.5.5.3 should be changed from “UNKNOW” to “UNKNOWN”
2.2.5.4.10.2 Authenticator state diagram
The authenticator state diagram is described in clause 8.5.6.
The following changes should be made to item 1 on p. 112:
From “DEAUTHENTICATE” to “DISCONNECT”
From “AUTHENICATION” to “AUTHENTICATION, AUTHENTICATION2”
From “UPDATEKEYS, MICFAILURE and UPDATEKEYS to “PTKINITDONE,
UPDATEKEYS, INTEGRITYFAILURE and KEYUPDATE”
2.2.5.4.10.2.1 Authenticator state machine variables
The authenticator state machine variables are described in clause 8.5.6.2. The following
changes should be made to 802.11i Draft 3.0:
Line 15, p. 115; Change from “wants an SSID” to “wants a BSSID”.
Line 22, p. 116; Change “GkeyReady” to “GKeyReady”
Line 36, p. 116; Add to TimeoutEvt: "Note: The default timeout value for
receiving a EAPOL_Key packet is 100ms"
Line 37, p. 115; Add to TimeoutCtr: "Note: The default timeout counter is 3."
2.2.5.4.10.2.2 Procedures
The authenticator procedures are described in clause 8.5.6.3.
17
2.2.5.4.10.2.3 States
The authenticator states are described in clause 8.5.6.1. However, all of clause 8.5.6.1 in
Draft 3.0 should be replaced with the following:
DISCONNECT: This state is entered is an EAPOL-Key message is received and fails its
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 is
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 a RadiusKey is supplied it 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 should detect and recover from the situation, for example by doing 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 and 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 or not. 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.
18
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 needs to detect and recover
from this situation.
2.2.5.5 Example key exchanges

This section gives several examples of key exchanges using the state diagrams in the
previous section. The examples include:
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 needs to be
changed. When this event occurs will depend on the environment the network will
be in, possible times are:
1. Whenever a supplicant disassociates from an Authenticator. So no

supplicant after leaving the network can decrypt any traffic. This is
especially important for networks that do not use the Pairwise key for
unicast traffic protection.
2. Several times a day to reduce the leakage of information without taking

the overhead of updating the Group key every logoff.
2.2.5.5.1 Key Initialization (4-way handshake + Group key update)

An example 4-way handshake for key initialization is shown in Clause 8.5.3.10. An
analysis of the 4-way handshake is shown in Clause 8.5.3.11.
2.2.5.5.2 Group key update

An example 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 of 802.11 Draft 3.0.
The pseudo-code for temporal key processing is defined in subclauses 8.7.1 through
8.7.4.
19
The Per-MSDU Tx Pseudo-code of clause 8.7.1 should be changed as follows
if MPDU has a group RA and the Privacy subfield of the
Capability Information field in this BSS is set to 0 then
the MPDU is transmitted without protections
else // No key found so try either default WEP
if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] = null
then
if Ethertype is 802.1X then
transmit the MPDU without protection
else
discard the MSDU and generate an
MA-UNITDATA-STATUS.indication
primitive to
notify LLC that the entire MSDU was
undeliverable
due to a null WEP key
to
if MPDU has a group RA and the Privacy subfield of the
Capability Information field in this BSS is set to 0 or Ethertype is
802.1X then
the MPDU is transmitted without protections
else // No key found so try either default WEP
if dot11WEPDefaultKeys[dot11WEPDefaultKeyID] = null
then
discard the MSDU and generate an
MA-UNITDATA-STATUS.indication primitive to
notify LLC that the entire MSDU was undeliverable
due to a null WEP key
2.2.5.7 PRF
The pseudo-random function capabilities for WPA are described in clause 8.5.5.1.
Note: When the PRF is used to generate key material, it should never be used with the same
input parameters. Note the use of the Global Counter for generating unique nonces. The reason
for this is that outputs from shorter PRFs are prefixes of longer PRFs given the same input.
20
2.3 ASCII Password Support for Pre-Shared Key
WPA uses the password hash function described in Annex F.8 of 802.11i Draft 3.0 to
define the algorithm to generate the 256 bit key used in pre-shared key authentication.
It is recommended that users enter longer passwords than 8 characters (e.g. 20 characters
or longer).
3 Temporal Key Integrity Protocol (TKIP)

WPA uses the Temporal Key Integrity Protocol (TKIP) for data privacy. TKIP is
described in clause 8.3.2 (including subclauses) of 802.11i Draft 3.0. The following
changes should be made to the text provided in Draft 3.0.
Clause 8.3.2.2 – Figure 14; references to TSC should be replaced with IV
Clause 8.3.2.2 – The byte ordering of the first two bytes of the TSC within the frame are
reversed by changing the next to last paragraph to RC4Key[0] = TSC1 and RC4Key[2] =
TSC0
Clause 8.3.2.4.3 – p 43, line 401; “The first 80 bits of TK …” is not correct. All 128 bits
of TK are used.
The references to TK12 in Figure 18, p 44, should read TK15.
The following changes should be made to Figure 18, p44:
Phase1-key-mixing
TTAK0 ← TSC0
TTAK1 ← TSC1
should be
TTAK0 ← TSC1
TTAK1 ← TSC2
The sentence “Only the last 24 bits of TK are used in Phase 2” of line 36, p44 should be
removed.
The phase 2 key mixing function provided on p 45 should be changed as follows:
Line 18, TK should be replaced with TK0…TK15
Line 18, TSC should be replaced with TSC0…TSC2
Line 40, TSC should be replaced with TSC0
In section 8.3.2.4.4, bullet 3, TSCs should be initialized to one instead of zero.
In section 8.3.2.4.4 bullet 5, add “to zero” after “The receiver initializes the replay
window”.
21
The following rule should be added to Clause 8.3.2.4.4:
“The recipient shall maintain a separate replay window for each IEEE 802.11 Traffic
Class, and shall use the TSC recovered from a received frame to detect replayed frames.
A replayed frame occurs when the TSC extracted from a received frame is repeated or
not greater than the current Traffic Class replay window value for the frame’s traffic
class. The replay window accommodates frames that may be delayed due to traffic class
priority values.”
Note: TKIP Replay protection rules means that certain features that re-order packets will
not work:
1. Use of Contention Free without 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 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

This section replaces the countermeasures describd in clause 8.3.2.4.2 of TGi.
Michael’s design trades off security in favor of implementability on pre-RSN equipment.
Michael provides only weak protection against active attack. A failure of the Michael
MIC in a received MSDU indicates an active attack. A successful attack against the MIC
would mean an attacker could inject forged data frames, and perform further effective
attacks against the encryption key itself . If a STA or AP/STA detects a probable active
attack, that STA shall take countermeasures as specified in this clause. These counter-
measures accomplish the following goals:
 MIC failure events must be logged as a security-relevant matter. A MIC failure is

an almost certain indication of an active attack, and warrants a follow-up by the
system administrator.
 The rate of MIC failure events must be kept below two per minute. This implies
that STAs and APs detecting two MIC failure events within 60 seconds must
disable all receptions using TKIP for a period of 60 seconds. The slowdown
makes it difficult for an attacker to make a large number of forgery attempts in a
short time.
 As an additional security feature, the PTK and, in the case of the authenticator,
the GTK will be changed. This is not required to defend against the known MIC
attacks, but is good practice when an attack of any kind is detected.
Before verifying the MIC, the receiver shall check the FCS, ICV, and IV for all related
MPDUs. MPDUs with invalid FCSs, ICVs, or with whose MPDUs’ IVs falling before
the IV window shall be discarded before checking the MIC. This avoids unnecessary
MIC failure events. Checking the IV before the MIC makes countermeasure-based DoS
attacks harder to perform. While the FCS and ICV mechanisms are sufficient to detect
22
noise, they are insufficient to detect active attacks. The FCS and ICV provide error
detection but not integrity protection.
A single counter or timer is used to log Michael MIC failure events. These failure events
are defined as:
1. For an Authenticator:
• Detection of a Michael MIC failure on a received unicast frame
• Receipt of Michael MIC failure report via an EAPOL Key frame with the
following bits in the Key Information bit set to 1: error bit , request bit,
MIC bit. This frame is referred to as the Michael MIC failure report
frame.
2. For a Supplicant:
• Detection of a Michael MIC failure on a received unicast or multicast
frame
The number of Michael MIC failures is accrued independent of the particular key
context. Any single MIC failure, whether detected by the Supplicant or the
Authenticator, and whether resulting from a Group MIC key failure or a pairwise MIC
key failure, shall be treated as cause for a MIC failure event.
A single IEEE 802.1X EAPOL Key message is used by the Supplicant to report a
Michael MIC failure event to the Authenticator. This message is referred to as the
Michael MIC failure report frame and is protected with the current PTK to compute an
appropriate 802.1X EAPOL MIC and encrypted as all normal IEEE 802.11 data frames.
The frame shall also have the following Key Information bits set to 1:, error bit, request
bit, MIC bit.
The first Michael MIC failure must be logged and a timer is initiated to enforce the
countermeasures. If the MIC failure event is detected by the Supplicant, it must also
report the event to the AP by sending a Michael MIC failure report frame.
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 the 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.
23
The aMICFailTime attribute shall contain the sysUpTime value at the time the
Michael MIC failure was logged. When the STA from which the AP received any
previous Michael MIC errors leaves the BSS, the AP shall not update this variable as a
result of this action.
The countermeasures used by an Authenticator is depicted in Figure 2 and described

below.
• For an Authenticator which 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 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.
Note that 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.
Informative Note: since an access point may support ciphers other than TKIP,
the Authenticator may disassociate all STAs who are employing TKIP while
allowing non-TKIP running STAs to remain associated.
Informative Note: It is an implementation decision whether an AP will continue to

transmit Beacons and Probe Responses during the lock out period, and also
whether those frames will indicate support for TKIP or not.
Informative 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.
24
Informative Note: since a single multicast frame can trigger multiple Michael
MIC Failure reports, to prevent this single frame to force 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.
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 2 Authenticator Countermeasures
The countermeasures used by a Supplicant is depicted in Figure 3 and described

below.
• For a Supplicant which detects a MIC failure event due to a unicast or

multicast Michael MIC failure:
1. Increments 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
25
forged, as it does not contain a MIC. The STA may attempt association
with this, or another AP. If the frame was genuine, then it is probable that
attempts to associate with the same AP requesting the use of TKIP will
fail because the AP will be conducting countermeasures.
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 3 Supplicant Countermeasures
3.1.1 10.3.13 Michael MIC Failure Event
3.1.2 10.3.13.1 MLME-MichaelMICFailure.indication
3.1.3 10.3.13.1.1 Function

This primitive reports that a Michael MIC Failure event was detected.
3.1.4 10.3.13.1.2 Semantics of the service primitive

The primitive parameters are as follows:
MLME-MichaelMICFailure.indication {
Count
}
26
Name Type Valid Range Description
Count Integer 1 or 2 the current number of Michael MIC failure
event
3.1.5 10.3.13.1.3 When Generated

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

The SME is notified that the MAC has detected a Michael MIC failure.
3.1.7 10.3.13.2 MLME-MichaelMICFailure.request
3.1.8 10.3.13.2.1 Function

This primitive reports that a Michael MIC Failure event was detected from
another STA.

There are no parameters for this primitive
3.1.10 10.3.13.1.3 When Generated

This primitive is generated by the SME when it has received an IEEE 802.1X
EAPOL Key message reporting a detected Michael MIC failure.

The MAC is notified that the Michael MIC failure must be logged and
countermeasures enforced.
3.1.12 10.3.14 EAPOL (Michael MIC Failure Report)
3.1.13 10.3.14.1 MLME-EAPOL.request
3.1.14 10.3.14.1.1 Function

This primitive indicates that this EAPOL message shall be confirmed.

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

Range
Source MAC address N/A The MAC sublayer address to which
Address the EAPOL message 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 message to be transmitted
EAPOL Key
frame
10.3.14.1.3 When Generated

This primitive is generated by the SME when an EAPOL message has been
ACKed.

The MAC is notified that this EAPOL message must be ACKed.
3.1.17 10.3.14.1 MLME-EAPOL.confirm
3.1.18 10.3.14.1.1 Function

This primitive indicates that this EAPOL message has been ACKed by IEEE
802.11.

There are no parameters for this primitive.
10.3.14.1.4 When Generated

This primitive is generated by the MAC when an EAPOL message has been
ACKed.

The SME is notified that this EAPOL message has been IEEE 802.11 ACKed.
28
29
3.2 Multicast/Broadcast data packets to AP
An AP should drop any data MSDU packets whether multicast/broadcast receiver addresses it
receives from stations.
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 MIC'd with the data portion of the MSDU are DA
and SA, which are the ultimate destination and source of the packet, and not
the TA and RA. Note that the DA and SA are in different positions of the
802.11 header depending on whether you're sending to or from the AP.
4. The MIC key used on the Client for TX is in bytes 24-31 and the MIC key
used on the Client for RX is in bytes 16 - 23 of the Pairwise Transient key.
That is, assume that Tx MIC and Rx MIC referred to in clause 8.7 of
802.11i Draft 3.0 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 to ensure MIC is calculated on
a multiple of 4-byte words).
6. The pad bytes above 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 are 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 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. In the Client that
would be its own address for TX P1k and the AP's Address for RX P1K.
10. The Phase 1 key is initialized when you receive the Add Key from NDIS.
That is, assuming you initialize the TSC to 0's, then you need to run the P1K
on the 0's TSC before you use the key 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
30
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 should have a key id of 0.
Group Keys created by the AP should have a key ID of 2 or 3.
13. The TSCs are saved in memory and used in LSB to MSB order.
4 Layer Management Updates

WPA updates the layer management of the original IEEE 802.11 1999 Standard per the
following clauses from 802.11i Draft 3.0:
10.3.2.2.2
10.3.6.1.2
10.3.6.3.2
10.3.7.1.2
10.3.8.1.2
10.3.11 (including all subsections)
10.3.12 (including all subsections)
5 MAC Sublayer Management Updates

WPA updates the sublayer management of the original IEEE 802.11 1999 Standard per
the following clauses from 802.11i Draft 3.0:
11.3.1
11.3.2
11.3.4
31
Appendix A: Removed
Appendix B: TKIP algorithm reference implementations

and test vectors
A TKIP reference implementation and test vectors are provided in Annex F.1 and
subclauses of 802.11i Draft 3.0.
Appendix C: Michael reference implementation and test

vectors
A Michael reference implementation and test vectors are provided in Annex F.2 and
Appendix D: 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 AESWRAP 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;
32
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;
33
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 = AESWRAP;
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;
34
oui03, 4))
unicast[j++] = AESCCMP;
oui04, 4))
unicast[j++] = AESWRAP;
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) {
35
caps = (char *)ieauth->auth[n].oui;
unicastasgroup = (*caps)&GROUPFLAG;
replayindex =
2<<((*caps>>REPLAYBITSSHIFT)&REPLAYBITS);
}
}
}
char *cip[] = { "", " WEP40", " TKIP", " AES-CCMP", "AES-WRAP",
“WEP104” };
char *cip1[] = { " NONE", " WEP40", " TKIP", " AES-CCMP", "AES-WRAP",
“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
36
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 E: HMAC_MD5, HMAC_SHA1 and PRF

reference
A reference implementation and test vectors for HMAC-MD5 are provided in Annex F.3
and subclauses of 802.11i Draft 3.0.
A reference implementation and test vectors for HMAC-SHA1 are provided in Annex F.4
and subclauses of 802.11i Draft 3.0.
37
A reference implementation and test vectors for PRF are provided in Annex F.5 and
Appendix F: ASCII Password reference

A reference implementation for ASCII password support is provided in Annex F.8 and
subclauses of 802.11i Draft 3.0 with the following changes.
It is recommended that users enter longer passwords than 8 characters (e.g. 20 characters
or longer).
The legal characters to use in a pass phrase are those whose encoding in the ASCII
character set are in the range 32-126 (decimal) inclusive.
Add the following as the first executable statements of function F().
for (i = 0; i < strlen(password); i++) {

assert((password[i] >= 32) && (password[i] <= 126));
}
The first call to hmac-sha1 in the reference code should read
hmac_sha1(
digest, ssidlength+4,
(unsigned char *)password, (int)strlen(password),
digest1);
The second call to hmac-sha1 in the reference code should read
hmac_sha1(
digest1, A_SHA_DIGEST_LEN,
(unsigned char *)password, (int)strlen(password),
digest);
The test vectors should read

Password=”password” SSID=”IEEE” SSIDLength=4
f42c6fc52df0ebef9ebb4b90b38a5f902e83fe1b135a70e23aed762e9710a12e
Password=”ThisIsAPassword” SSID=”ThisIsASSID” SSIDLength=11

0dc0d6eb90555ed6419756b9a15ec3e3209b63df707dd508d14581f8982721af
Password=”aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”
38
SSID=”ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ” SSIDLength=32
becb93866bb8c3832cb777c2f559807c8c59afcb6eae734885001300a981cc62
Appendix G: IEEE 802.1X State synchronization

This document assumes the synchronisation variables defined in 802-1aa-d4-1.pdf.
Appendix H: 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 there is no need to repeat that in this description. .
Client STA AP “Higher

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

MAC
Figure 4 - System Structure
39
State 3
Frame with Yes

MIC failure MLME-
MichaelMICFailure
.indication
detectTimer (second)
running &&
No The idea is to
detectTimer
< 60? speed up
‘Drop as many
transmission of the
frames from the TX
EAPOL-Key
MLME- queue as possible’
messager that is
MichaelMICFailure.
about to be sent.
indication (first)
‘Start 60 second
blockingTimeout’
‘Start detectTimer’
Blocking
State 3
Figure 5 - Client STA MAC Part 1
40
Blocking
MLME- MLME- MA-

EAPOL.request DISASSOCIATE MLME- Received data
ASSOCIATE UNITDATA.req
.request frame
.request uest
‘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 6 - Client STA MAC Part 2
41
Normal
Wait for frame

status
MLME-
MichaelMICfailure
.indication (count)
Note that this yes MLME-

frame must be EAPOL.confirm
MLME-
given a correct
EAPOL.request
LLC/SNAP header
(EAPOL-Key with MIC
despite apparently
failure report) TO AP
avoiding the LLC/
SNAP layers MLME-
DISASSOCIATE
.request
Count =
2?
No Wait for
disassociation
confirm
Normal
Figure 7 - Client STA Higher Layer Software
42
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 8 - AP MAC
43
*
EAPOL-Key with
MIC failure
indication
MLME-
MICfailure.re
quest
Figure 9 AP Higher Layer Software
Appendix I: WPA Requirements

Function Required/Recommended/Optional
48 bit 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
De-fragmentation of TKIP data packets Required
Use of integrity check and IV for replay protection Required
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
44
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 key Required
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
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 power Required
save
Saving of IBSS IV Required
Support for RADIUS Required for AP
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
45
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 J: Suggestions for random number generation

Suggestions for random number generation are addressed by Annex F.9 and subclauses
of 802.11i Draft 3.0.
46

WPA WPA Eap Artikel Revised de Rev2

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

WPA WPA Eap Artikel Revised de Rev2

Încărcat de

Drepturi de autor:

Formate disponibile

Wi-Fi Protected Access (WPA)

Wi-Fi Alliance CONFIDENTIAL

2.1 Advertisement of WPA Availability 9

2.2 Authentication and Association Overview 10

2.3 ASCII Password Support for Pre-Shared Key 21

3 TEMPORAL KEY INTEGRITY PROTOCOL (TKIP) 21

3.2 Multicast/Broadcast data packets to AP 30

3.3 TKIP and Michael implementation checklist 30

4 LAYER MANAGEMENT UPDATES 31

5 MAC SUBLAYER MANAGEMENT UPDATES 31

APPENDIX B: TKIP ALGORITHM REFERENCE IMPLEMENTATIONS AND

APPENDIX C: MICHAEL REFERENCE IMPLEMENTATION AND TEST

APPENDIX D: WPA INFORMATION ELEMENT REFERENCE

APPENDIX E: HMAC_MD5, HMAC_SHA1 AND PRF REFERENCE 37

APPENDIX F: ASCII PASSWORD REFERENCE 38

APPENDIX G: IEEE 802.1X STATE SYNCHRONIZATION 39

APPENDIX H: MICHAEL COUNTERMEASURES STATE MACHINES 39

APPENDIX I: WPA REQUIREMENTS 44

The following notes will be useful in the development of a WPA implementation.

The configuration options a station should support are:

2.1 Advertisement of WPA Availability

2.2 Authentication and Association Overview

2.2.2 Encrypted/Unencrypted data handling

2.2.3 Authentication and key management overview

2.2.3.1 Mandatory Authentication and Key Management

p79, line 20 - Add a bullet “A STA must support a contiguous range of

2.2.3.2 Optional IBSS Global pre-shared key system

Figure 1—Global Pre-shared State Machine

2.2.4 EAPOL-Key messages

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.4 Coordination of Authentication Process

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.9 4-way Handshake

2.2.5.4.10 State diagrams

2.2.5.5 Example key exchanges

This occurs whenever a Supplicant authenticates to an Authenticator.

2. Updating the Group key

1. Whenever a supplicant disassociates from an Authenticator. So no

2. Several times a day to reduce the leakage of information without taking

2.2.5.5.1 Key Initialization (4-way handshake + Group key update)

2.2.5.5.2 Group key update

2.2.5.6 Temporal keys processing rules

3 Temporal Key Integrity Protocol (TKIP)

3.1 Active Countermeasures

 MIC failure events must be logged as a security-relevant matter. A MIC failure is

The countermeasures used by an Authenticator is depicted in Figure 2 and described

1. Increment the MIC failure counter

4. If the Authenticator is using EAP, transition the state of the Authenticator

5. Log details of the Michael MIC failure.

Informative Note: It is an implementation decision whether an AP will continue to

Timer < 60 No Timer = 0 Continue

Wait 60 Seconds Plumb new GTK,

Figure 2 Authenticator Countermeasures

The countermeasures used by a Supplicant is depicted in Figure 3 and described

• For a Supplicant which detects a MIC failure event due to a unicast or

1. Increments the MIC failure counter.

2. Send a Michael MIC failure report frame to the AP.