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 2
2.1 2.2 2.3

INTRODUCTION WPA OVERVIEW
Advertisement of WPA Availability Authentication and Association Overview ASCII Password Support for Pre-Shared Key

4 5
9 10 21

3
3.1 3.2 3.3

TEMPORAL KEY INTEGRITY PROTOCOL (TKIP)
Active Countermeasures Multicast/Broadcast data packets to AP TKIP and Michael implementation checklist

21
22 30 30

4 5

LAYER MANAGEMENT UPDATES MAC SUBLAYER MANAGEMENT UPDATES

31 31 32

APPENDIX A: REMOVED

APPENDIX B: TKIP ALGORITHM REFERENCE IMPLEMENTATIONS AND TEST VECTORS 32 APPENDIX C: MICHAEL REFERENCE IMPLEMENTATION AND TEST VECTORS APPENDIX D: WPA INFORMATION ELEMENT REFERENCE IMPLEMENTATION APPENDIX E: HMAC_MD5, HMAC_SHA1 AND PRF REFERENCE APPENDIX F: ASCII PASSWORD REFERENCE APPENDIX G: IEEE 802.1X STATE SYNCHRONIZATION APPENDIX H: MICHAEL COUNTERMEASURES STATE MACHINES APPENDIX I: WPA REQUIREMENTS
Wi-Fi Protected Access Version 2.0 – April 29, 2003

32

32 37 38 39 39 44

Wi-Fi Alliance CONFIDENTIAL

2

APPENDIX J: SUGGESTIONS FOR RANDOM NUMBER GENERATION

46

Wi-Fi Protected Access

Version 2.0 – April 29, 2003

Wi-Fi Alliance CONFIDENTIAL

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.

Wi-Fi Protected Access

Version 2.0 – April 29, 2003

Wi-Fi Alliance CONFIDENTIAL

4

Configuration of cipher suites is also supported. AP: Implementations of WPA will need a configuration utility or similar to configure the pre-shared key.3.0 7.1X on the AP needs to be able to configure temporal keys into the 802.4 Wi-Fi Protected Access Version 2.2. 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.11i Draft 3. 2003 Wi-Fi Alliance CONFIDENTIAL 5 .11 MAC.11i Draft 3.2 8.1.11 standard as described in the following clauses of 802.1X should update the group key. This is implementation dependent and will not be defined here. 2 WPA Overview WPA supports the changes to the 1999 802.4 7.1.3.2.1 7.3.3.3. Configuration of cipher suites is also supported.2.0 – April 29.6 7.3.1.1. This is implementation dependent and will not be defined here. 802.3. If the key is entered as an ASCII password the 256bit key must be generated as described in Section 2. This is implementation dependent and will not be defined here.1.2.1.0 8. This is implementation dependent and will not be defined here.9 7. This is implementation dependent and will not be defined here. The AP control panel will also need to provide configuration for the interval at which 802. 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.2.1 8.3 8.9 7.10 The framework and operation of WPA are described in the following clauses of 802.2 7.2.1 (TKIP only) 8.

WPA b. Select the AP configurations the station will associate to a. WEP rekeying using the existing 802. When configured to allow association of non-WPA stations. AES 3. then they should not be advertised in the WPA IE for the AP/station. 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. WEP c. Pre-shared key for WPA which can be an ASCII passphrase or a 256 bit key 4. TKIP b. Select one or more station configurations to associate to the AP a.5 8. 2. Pre-shared key for WPA which can be an ASCII passphrase or a 256 bit key 4. AES 3. WEP key for static WEP stations which can be 40 or 104bits in length The configuration options a station should support are: 1. For WPA select the cipher to use for unicast a.8.1.0 – April 29. The configuration options an AP should support are: 1. Wi-Fi Protected Access Version 2. 2003 Wi-Fi Alliance CONFIDENTIAL 6 . If the network administrator doesn’t want particular ciphers to be used. WEP 2. WPA b. 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.2 (including all subsections) The following notes will be useful in the development of a WPA implementation. For WPA select the list of available ciphers for unicast a.1X EAPOL-key message. since the pre-shared key is used as the PMK impersonation between stations or a station impersonating an AP is possible. APs advertise their capabilities in a WPA information element (IE). the multicast cipher should be WEP. TKIP b.

The association request message specifies the unicast and multicast ciphers it wants.1X authentication). In this case the AP can use 802. The policy configuration could include the ciphers the station is willing to use.1X to send WEP key updates to the station. though they may use different keys for the unicast traffic if supported by the station and AP. it should be possible to enter a default WEP key and disable group key updating to support case 2.4 If the station does not receive a WPA information element in the Beacon or Probe Response. 2. Note: The AP should have a way to disable non-WPA clients from associating. the AP shall follow the normal 802. if WEP is enabled in 1 then the multicast is WEP.1X supplicant.1X supplicant that is a non-WPA 802.1X is enabled on the AP then 802. etc. If the AP does not receive a WPA information element in the Association Request. The non-WPA station does not support an 802. whether the station is willing to allow Group keys to be used for unicast. The non-WPA station supports an 802.1X authentication and 802. there are a couple of cases to consider: 1. Since the AP for broadcast/multicast traffic must use the pre-configured key. A non-WPA supplicant only supports group keys and so the AP must track per station whether it supports unicast keys or not.1X key management. the station shall follow the normal 802.1X should be used to update the group key on non-WPA stations. The AP shall use WPA Group key exchange to send the fixed WEP key to the WPA stations. If the authentication suite is WPA-PSK then it should do 802. Based on the station encryption/integrity capabilities and policy configuration of the ciphers the station is willing to communicate with.1X key management is the term used for managing the keys using IEEE 802.2.1X EAPOL-Key message as described in Section 2. If only WPA is enabled in 1 and TKIP is enabled in 2. it must use WPA key update exchanges to send the key to the WPA stations. If only WPA is enabled in 1 and only AES is enabled in 2.11 association processing (This may include the current 802. Then the WEP key must be pre-configured into the non-WPA station and AP.1X key management. If the AP supports WPA and non-WPA stations. 2003 Wi-Fi Alliance CONFIDENTIAL 7 . This means that the WPA stations in this configuration will have fixed keys for broadcast/multicast traffic. then the multicast cipher is TKIP.11 authentication (This may include the current 802. When WPA and non-WPA stations are both enabled. then the multicast cipher is AES.The multicast cipher must always be the lowest unicast cipher enabled. So.0 – April 29.1X supplicant. the station decides which APs it is willing to use. If the station or AP receives a WPA information element with an authentication suite of WPA.1X authentication). group key updating should be enabled and if 802. then it should do 802. By default. the authenticated key management the station is willing to use. given the Wi-Fi Protected Access Version 2. Note: 802. The station then associates with the AP using an association request message. Stations get the WPA information element from the beacon or probe response messages.

Otherwise it can send the pre-configured key to all stations as they associate. the multicast cipher is from multicast cipher selection and the unicast cipher is from unicast cipher selection. If an AP supports non-WPA open or shared stations then the open or shared station bypasses the 1X port switch.1X with the AP. when this document talks about sending an 802. that new station must use the pre-configured key for broadcast/multicast. 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. Note: In general.11 association response message (with Reason code 1) if it didn’t like something in the WPA information element.1X or WPA wants to 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.11 1999 standard. and then send the preconfigured key to the existing stations (so that all stations will then be using the preconfigured key).station’s cipher capabilities and configuration.0 – April 29. When the AP receives the RADIUS accept. 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. and a station that does not use 802. The AP sends an 802.11 disassociation and/or 802. 2003 Wi-Fi Alliance CONFIDENTIAL 8 . The following table describes the various configuration options and the expected system behavior. When the station receives the association response it authenticates using 802. 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.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. The AP then does an EAPOLKey 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. the AP then sends an EAP-Success to complete the authentication at the station.1X and WPA stations. Wi-Fi Protected Access Version 2.11 deauthenticate message it means that the 802. When a station or AP fills the WPA information element.

WPA uses the RSN Information Element described in clause 7.1 Advertisement of WPA Availability Advertisement of WPA availability will be done by a propriety information element in the beacon. association request and re-association request messages.3. probe response. An additional 4 octets is inserted before the Version field containing an OUI and type fields of 00:50:F2:01. Version 2. 2003 Wi-Fi Alliance CONFIDENTIAL Wi-Fi Protected Access 9 . The beacon or probe response messages contain the capabilities of an IBSS station.Network Authentication Type mode or authenticated key management ESS ESS ESS ESS ESS ESS ESS ESS ESS ESS IBSS IBSS IBSS IBSS IBSS IBSS IBSS Open Open Shared Shared WPA WPA WPA WPA-PSK WPA-PSK WPA-PSK Open Open Shared Shared WPA-None WPA-None WPA-None Encryption status Manual Key required? 802. 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.17 with the following changes • • The Element ID of page 19.1X enabled? None WEP None WEP WEP TKIP AES WEP TKIP AES None WEP None WEP WEP TKIP AES No Optional Yes Optional No No No Yes Yes Yes No Yes Yes Yes Yes Yes Yes No Optional No Optional Yes Yes Yes Yes Yes Yes No No No No No No No Note: Manual Key required is whether a key is required for this mode to work.0 – April 29. 2. line 10 shall be 221 instead of 48.2.

Select a network i.1X authentication. 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. (Re-)Associating and then doing 802.1X authenticated key management 5.11i Draft 3. Initiate 802. • • • Note: “Authenticated Key Management using pre-shared key over 802.0 – April 29.Request 3 is the management entity associating to a BSSID. Note: Element ID 221 is also used for vendor extension. 2. 4 is the management entity initiating 802.1X” means that any STA that has the key can impersonate any other STA.e. specifying a SSID 2.0 for definitions of WRAP and CCMP). Associate to a chosen APs 4. 2003 Wi-Fi Alliance CONFIDENTIAL 10 .2 Authentication and Association Overview Connecting to an AP consists of the following operations: 1. Install the keys obtained from authenticating to the AP 1 is internal to the management entity choosing the SSID for 2. WPA has TKIP as default rather than CCMP. 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 Wi-Fi Protected Access Version 2. Find APs that are nearby for the selected SSID 3. 5 is the management entity calling MLME-SetKeys. 2 is the management entity calling MLME-Scan.2.Request Roaming can be done either by 1. 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. it reserves the codes (per Table 2 of page 20) but doesn't define the encryption schemes (See IEEE 802.2. The preauthentication bit (p21.1X authenticated key management by sending an AuthenticationRequest to the Supplicant as described in Section 2. 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.• • The OUI shall be 00:50:F2 instead of 00:00:00.11i must be used. WPA doesn't ignore WRAP and CCMP. line14 and Figure 8) should always be 0. Note: An AP that does not install the Pairwise keys means that stations can impersonate each other.

An AP must complete 802.1X messages will be encrypted and protected against spoofing. IEEE 802. 2. obtain and install keys before attempting to send class 3 data packets on or off the DS for a station.1X.e.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. a station may try again or attempt to authenticate to another AP. If the AP fails during authentication. 7. Select a network i. obtain and install keys before attempting to send class 3 data packets other than 802. since stations cannot spoof each others MAC address and IEEE 802. it shall send a deauthenticate message to the station on receiving any message from a station. If the IEEE 802.AP that the keys were obtained from. 9. Find a WPA IBSS station that is nearby for the selected SSID 3.1X messages are not encrypted using Group keys. The station shall delete the keys when it disassociates/deauthenticates from all BSSIDs in the ESS. the station is asleep. If the AP does not have the station authenticated. Install the pre-shared key 1 is internal to the management entity choosing the SSID for 2.1 Associate/Re-Associate The following rules should be applied: 1. resource shortages. 4. Note: The use of Pairwise keys is more secure than the use of only Group keys.1X. it sends a deauthenticate message. 2 is the management entity calling MLME-Scan. This is if the AP wants to recover the resources used by a stations’ association. etc. Wi-Fi Protected Access Version 2. Connecting to an IBSS station consists of the following operations: 1. The AP may not be able to send the message because the station is out of range. etc. IEEE 802. 6.11 open authentication. A station must use IEEE 802. The AP should attempt to inform the station by sending a deauthentication message. A station must complete 802.Request 3 is the management entity calling MLME-SetKeys. 8.2. the AP may queue the message. specifying a SSID 2. 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.Request 2.1X authentication fails. If the AP cannot send the EAPOL-Key message containing a Group key update to a station. An AP can delete a station’s state if it requires to because of inactivity timeout. 2003 Wi-Fi Alliance CONFIDENTIAL 11 .1X 3.0 – April 29. 5.

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. 2003 Wi-Fi Alliance CONFIDENTIAL 12 .2.3.2 Station A station on receiving a disassociate message or an 802.4. 2.2. 2. The only unencrypted data packets allowed are unicast 802.11 deauthenticate message should delete the Pairwise key and attempt to rejoin the network (i.9 and subclauses The security association management of WPA is described in the following clauses: 8.2.4.2.4.2.4 5.1X as described in the following clauses in 802. 5.4 5.3 and subclauses (References to TKIP only) 5.11i Draft 3.2.2.The Authenticator state machine will eventually timeout the acknowledgement message for the Group Key update but the L2Failure optimizes the detection of the failure. reassoicate to an AP if the station was a member of an ESS). If the station and AP key state get out of synchronization the following rules apply: 2.3 5.1X data packets and unencrypted 802. it should send a disassociate message to the station and discard the data packet.2 5.1 Mandatory Authentication and Key Management The authentication and key management model for WPA is based on 802.1.e.2.2 Encrypted/Unencrypted data handling Under normal circumstances the station and APs will either send encrypted data or unencrypted data packets.1. 2.2.4.2 5.0 – April 29.0.1.1.1. 2.2. except for text relating to pre-authentication and IBSS Wi-Fi Protected Access Version 2.5 5.2.1 AP If the AP receives a unicast encrypted packet that it does not have keys to decrypt.1X data packets are only allowed when there is no Pairwise key between the station and AP otherwise unencrypted data packets must be discarded.4.

2.6. with the following exception. IBSS is not supported in Wi-Fi Protected Access and this paragraph is provided for information only.1 8.2 Optional IBSS Global pre-shared key system The following paragraph describes a simple approach to IBSS. 2003 Wi-Fi Alliance CONFIDENTIAL 13 . line 8. line 20 .5 8.6 (excluding 8.4. it cannot cause a key change.4.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.2 8. 2.4. 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. Note: This does not provide the level of security that the Authentication Server system provides.4.4.” 8. A WPA compliant device may optionally ignore the frame in question.4.4.4.8.3. Wi-Fi Protected Access Version 2.3.Add a bullet “A STA must support a contiguous range of versions.0 – April 29.10. 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.1. A pre-shared key is configured as a Group key and no authentication is carried out (even though IEEE 802.3 p79.1) 8. This system is meant for a very simple IBSS usage.10. including subsections.4.4. A data integrity failure can only be logged.1 8.11 authentication frames are exchanged).8 8.

Bits 4 and beyond should be decremented by 1 for consistency with Figure 49 of p.0 – April 29.5.8 to describe the mapping of the pairwise and group transient keys to the TKIP and WEP encryption protocols respectively. 2003 Wi-Fi Alliance CONFIDENTIAL 14 . 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.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.9 of IEEE 802. so for example it is possible to store a single IV for use with all the IBSS pre-shared keys. PRF-104 for support of WEP-40 and WEP104 as group keys in a transitional network with WEP clients. it is possible to share the IV across the different pre-shared keys.2. Note: There is an inconsistency in the reference to the bit descriptions in the key information field in Draft 3.4 EAPOL-Key messages WPA uses the EAPOL-Key messages of clause 8.0. Since the time for a single IV is over 800 years (or 100 years with N = 1.1X as described in clause 5.1.5. 2. Note: The station needs to track the receive IV for each station in range.3 should also reference PRF-40. and clause 8.1.11i Draft 3.7.11i Draft 3. clause 8. Clause 8. Note: The key descriptor type 1 should not be used when an AES cipher is used.2. Wi-Fi Protected Access Version 2.2.6. See 802.000. 92. A value of N of 1.2.5.2.11 Keys WPA uses clause 8. 2.1 Key hierarchy WPA uses the TKIP and WEP encryption key hierarchies described in clause 8. 2.1.5 802.1X authentication WPA uses 802.000) sharing the IV doesn’t cause a problem.6.11i Draft 3. 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.2 of 802. Clause 8.5.1 should also show support for PRF-40 and PRF-104.6.11a MAC the IV will last over 100 years. clause 8.6.0.5. 2.000.0 for the key descriptor type to be used when an AES cipher is used. Note: While a different IV can be used for each pre-shared key.000 means that if the system is restarted once per minute and the system is transmitting packets as fast as possible over an 802. Note: The IV shall be initialized to a random 48 bit value when a stored IV is not available.2 Mapping EAPOL Keys to 802.0 to provide the framework for AP/Station authentication.1 and it’s sub-clauses for pairwise keys and group keys.5.

5.4.5.11i Draft 3.3. not necessarily 16 octets.5.6.3.2. 2.4. with the exception of references to pre-authentication.2 – Line 26.4. 99. p. Wi-Fi Protected Access Version 2.5. 105. The key length is the length of the temporal key.3 Group key update The handshake used by WPA for the group key update is described in clause 8. Clause 8.2 4-way handshake The 4-way handshake used by WPA is described in clause 8. The key length is 0.2.11i Draft 3.5.3.2. The key length is the length of the temporal key and not necessarily 16 octets as shown. p.5. p.1. p. – Line 33. The keyID is 0.3 Nonce Generation WPA uses the nonce generation conventions defined in clause 8.2.0: Clause 8. The key length is the length of the temporal key. if not then the Key Counter may be predicable and previous 4-way handshakes can be replayed. 106.3. 2003 Wi-Fi Alliance CONFIDENTIAL 15 . 2.5.5.7. 106.0: Clause 8. p.5. 100.4.5.1 ESS Authentication Authentication in the ESS environment is described in clause 8.4 – Line 22.2 – line 41. p.4.5.5.5. Clause 8. which is not supported in WPA.2.2. Clause 8. The following changes should be made to the text of 802.5.2 – line 33. 98.3 – Line 22. The following changes should be made to the text of 802. 101.1 – line 38.2.4 Coordination of Authentication Process 2. The Key Length is 0. Note: A good source of a random number is required to initialize the Key Counter.4 and its subclauses with the changes and corrections listed below. Clause 8.4.5. The notation used to describe the EAPOL-Key messages is described in clause 8. 2. The key length is 0.3 and its subclauses with the changes and corrections listed below.4. not necessarily 16 octets. Clause 8. p.0 – April 29.5.

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. do a 4-way handshake with the Supplicant and do a Group key update to all Supplicants.2. 2. Replay Counter = 1 Message 4: MIC = 1.5. 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. Replay Counter = 0 Message 2: MIC = 1.2. ACK = 0. This is used when the MAC detects a data integrity attack.2. A Michael MIC Failure message (see section 3. 2003 Wi-Fi Alliance CONFIDENTIAL 16 . Example 4-way handshake Message 1: MIC = 0.2. the authenticator shall change the Group key. but does not imply a request for key update.5 Use of the secure bit This is addressed in clause 8.2. ACK = 1.6 Use of the EAPOL-Key Replay Counter This is addressed in clause 8.4.4. Each message sent from the Authenticator must use a different replay counter and must have the ACK bit set. ACK = 0.0 – April 29. ACK = 1. 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.2.4.5. 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. Replays to a message from the Authenticator must use the same replay counter value and he ACK bit must not be set.2.5. If the EAPOL-Key message has a key type of Pairwise key. Wi-Fi Protected Access Version 2. ACK = 1. Replay Counter = 1 Example Group key Update Message 1: MIC = 1. If the EAPOL-Key message has a key type of Group key. Replay Counter = 2 Message 2: MIC = 1.5. 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. ACK = 0.5.1) has the Request bit set.7 Use of the EAPOL-Key Key Data for Pairwise keys This is addressed in the “Key Data” section of clause 8.5. Replay Counter = 2 2.5.4. Replay Counter = 0 Message 3: MIC = 1.2. 2.

and 8.5.3 the normal value of the Key RSC field is zero.5.1 should be changed from “to authenticate an SSID” to “to authenticate a BSSID” 2.4.2.2 Authenticator state diagram The authenticator state diagram is described in clause 8. 2.8 EAPOL-Key encoding This is addressed in clause 8.10.5.4. 116.1.5.3. 112: From “DEAUTHENTICATE” to “DISCONNECT” From “AUTHENICATION” to “AUTHENTICATION.11i Draft 3.5.2. 116.10.5.5. p. UPDATEKEYS.3. INTEGRITYFAILURE and KEYUPDATE” 2.1.10. p.2.5.2.1 of the Draft 2. 115. 2003 Wi-Fi Alliance CONFIDENTIAL 17 . AUTHENTICATION2” From “UPDATEKEYS. Change from “wants an SSID” to “wants a BSSID”.0: Line 15.2 Procedures The authenticator procedures are described in clause 8.2.5.5.2. MICFAILURE and UPDATEKEYS to “PTKINITDONE. Change “GkeyReady” to “GKeyReady” Line 36.6.4.10.9 4-way Handshake The 4-way handshake is decribed in clause 8.4.5. Line 9.5. 115. p.5.4.2. 108 of Clause 8.5.1 Supplicant state machine variables The WPA supplicant state machine variables are described in clause 8.2.4.3. Line 22. Add to TimeoutEvt: "Note: The default timeout value for receiving a EAPOL_Key packet is 100ms" Line 37." 2.5.2.2.6.5.5.3.4.2.5.2.10.5. The following changes should be made to 802.5.5.10. p.1.2 Procedures The WPA supplicant procedures are described in clause 8.3 should be changed from “UNKNOW” to “UNKNOWN” 2.4.4.10 2.2. 2.0 – April 29.5. with the exception that in clause 8.2.5. Wi-Fi Protected Access Version 2.5. Line 22.1 Authenticator state machine variables The authenticator state machine variables are described in clause 8.5. p.5. The following changes should be made to item 1 on p.1 State diagrams Station state diagram Station state diagrams for WPA are provided in clauses 8.6. Add to TimeoutCtr: "Note: The default timeout counter is 3. p. 110 of clause 8.2.5.

However. 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. REKEYNEGOTIATING: This state is entered when the Group key is to be sent to the Supplicant.0 – April 29. This state may call SetPTK. The state initializes the key state variables. all of clause 8.1X backend authentication server completes successfully. PTKSTART: This state is entered from INITPMK or INITPSK to start the 4-way handshake.2. DISCONNECTED: This state is entered when disassociate or deauthenticate messages is received.10. INITPSK: This state is entered when a pre-shared key is configured. or if no response to the 4-way handshake occurs. 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.5. otherwise it goes to the DISCONNECTED state.1.2.6. INITIALIZE: This state is entered from the DISCONNECTED state. when a DeauthenticationRequest event occurs or when the station initializes.5.6. AUTHENTICATION: This state is entered when an AuthentiationRequest is sent from the Management entity to authentication a BSSID.3 States The authenticator states are described in clause 8. 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.1 in Draft 3. 2003 Wi-Fi Alliance CONFIDENTIAL 18 .5. INITPMK: This state is entered when the 802.2. If a RadiusKey is supplied it goes to the PTKSTART state. Wi-Fi Protected Access Version 2.4. if this call fails the AP should detect and recover from the situation. for example by doing a Disconnect event for this association. KEYUPDATE: This state is entered from INTEGRITYFAILURE. 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. AUTHENTICATION2: This state is entered from the AUTHENTICATION state or from the PTKINITDONE state. 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. It sends a deauthenticate message to the Access Point and enters the INITIALIZE state.0 should be replaced with the following: DISCONNECT: This state is entered is an EAPOL-Key message is received and fails its MIC check.

1 Key Initialization (4-way handshake + Group key update) An example 4-way handshake for key initialization is shown in Clause 8. 2.REKEYESTABLISHED: This state is entered when an EAPOL-Key message is received from the supplicant with the key type set to Group key. 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.5. KEYERROR: This state is entered if the EAPOL-Key acknowledgement for the Group key update is not received.5.5 Example key exchanges This section gives several examples of key exchanges using the state diagrams in the previous section.7. SETKEYSDONE: This state is entered if the Group key has been updated on all Supplicants.11 Draft 3.3.1 through 8. Updating the Group key This occurs on a management event.2.7 of 802. This is especially important for networks that do not use the Pairwise key for unicast traffic protection. The examples include: 1.5.4. 2.6 Temporal keys processing rules The processing rules for temporal keys are specified in Clause 8. Wi-Fi Protected Access Version 2. 2. Several times a day to reduce the leakage of information without taking the overhead of updating the Group key every logoff.4.11.10. when the current Group key needs to be changed. An analysis of the 4-way handshake is shown in Clause 8.5.2. When this event occurs will depend on the environment the network will be in. So no supplicant after leaving the network can decrypt any traffic. possible times are: 1.5.4 2.7.5.0 – April 29.3.5.0.2. 2003 Wi-Fi Alliance CONFIDENTIAL 19 . The pseudo-code for temporal key processing is defined in subclauses 8.2. 2. SETKEYS: This state is entered if the Group key is to be updated on all Supplicants. Initialization of keys This occurs whenever a Supplicant authenticates to an Authenticator.2 Group key update An example group key distribution is shown in Clause 8.5.5. Whenever a supplicant disassociates from an Authenticator.

it should never be used with the same input parameters.1X then transmit the MPDU without protection else discard the MSDU and generate an MA-UNITDATA-STATUS. 2003 Wi-Fi Alliance CONFIDENTIAL 20 .indication primitive to notify LLC that the entire MSDU was undeliverable due to a null WEP key 2. The reason for this is that outputs from shorter PRFs are prefixes of longer PRFs given the same input.0 – April 29. Note: When the PRF is used to generate key material.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.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.5.5. Wi-Fi Protected Access Version 2.2.1.5.7.The Per-MSDU Tx Pseudo-code of clause 8.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. Note the use of the Global Counter for generating unique nonces.7 PRF The pseudo-random function capabilities for WPA are described in clause 8.

20 characters or longer). bullet 3. references to TSC should be replaced with IV Clause 8. In section 8.2 (including subclauses) of 802. TKIP is described in clause 8.3. 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.2. 2003 Wi-Fi Alliance CONFIDENTIAL 21 .3.0. TSC should be replaced with TSC0 Line 42. TSC should be replaced with TSC0…TSC2 Line 40. add “to zero” after “The receiver initializes the replay window”. “The first 80 bits of TK …” is not correct. It is recommended that users enter longer passwords than 8 characters (e.3. The following changes should be made to the text provided in Draft 3.0 – April 29. All 128 bits of TK are used. should read TK15.3. The references to TK12 in Figure 18. TSC should be replaced with TSC0 In section 8. The following changes should be made to Figure 18.0 to define the algorithm to generate the 256 bit key used in pre-shared key authentication.3 ASCII Password Support for Pre-Shared Key WPA uses the password hash function described in Annex F. p 44.3.2. Clause 8.4. TSCs should be initialized to one instead of zero.2.11i Draft 3.4.8 of 802.3.4.11i Draft 3. Wi-Fi Protected Access Version 2. line 401.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.2 – Figure 14.3 – p 43.2.g. The phase 2 key mixing function provided on p 45 should be changed as follows: Line 18.2. TSC should be replaced with TSC0 Line 41. p44 should be removed. 3 Temporal Key Integrity Protocol (TKIP) WPA uses the Temporal Key Integrity Protocol (TKIP) for data privacy.4.4 bullet 5. TK should be replaced with TK0…TK15 Line 18.2.0.

2 of TGi.The following rule should be added to Clause 8.4. A MIC failure is an almost certain indication of an active attack.11 Traffic Class. the receiver shall check the FCS. If a STA or AP/STA detects a probable active attack. Michael’s design trades off security in favor of implementability on pre-RSN equipment. Use of Contention Free without WME or 802. the GTK will be changed. A successful attack against the MIC would mean an attacker could inject forged data frames.11e will not work. or with whose MPDUs’ IVs falling before the IV window shall be discarded before checking the MIC. and warrants a follow-up by the system administrator.4. that STA shall take countermeasures as specified in this clause. Before verifying the MIC. 3.1 Active Countermeasures This section replaces the countermeasures describd in clause 8. 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. but is good practice when an attack of any kind is detected. in the case of the authenticator.4: “The recipient shall maintain a separate replay window for each IEEE 802.11e will not work unless encryption and integrity protection is done after any packet re-ordering. 3.2.  As an additional security feature. Checking the IV before the MIC makes countermeasure-based DoS attacks harder to perform. A failure of the Michael MIC in a received MSDU indicates an active attack. 2003 Wi-Fi Alliance CONFIDENTIAL 22 .” Note: TKIP Replay protection rules means that certain features that re-order packets will not work: 1. While the FCS and ICV mechanisms are sufficient to detect Wi-Fi Protected Access Version 2. The replay window accommodates frames that may be delayed due to traffic class priority values. MPDUs with invalid FCSs.2. the PTK and.  The rate of MIC failure events must be kept below two per minute. These countermeasures accomplish the following goals:  MIC failure events must be logged as a security-relevant matter.3. and IV for all related MPDUs. 2. This avoids unnecessary MIC failure events. Use of QoS without WME or 802. 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. Michael provides only weak protection against active attack. ICV.0 – April 29. This is not required to defend against the known MIC attacks.3. and perform further effective attacks against the encryption key itself . The slowdown makes it difficult for an attacker to make a large number of forgery attempts in a short time. ICVs. 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.

Detection of a Michael MIC failure on a received unicast or multicast frame 2. This frame is referred to as the Michael MIC failure report frame. Any single MIC failure. then a device will disassociate itself (if a Supplicant) or disassociate all the associated STAs (if an Authenticator). A single IEEE 802.1X EAPOL MIC and encrypted as all normal IEEE 802. the AP shall resume normal operations and allow STAs to (re)associate.0 – April 29. 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. A single counter or timer is used to log Michael MIC failure events. whether detected by the Supplicant or the Authenticator.noise. and whether resulting from a Group MIC key failure or a pairwise MIC key failure. When a subsequent MIC failure occurs within 60 seconds of the preceding failure. The FCS and ICV provide error detection but not integrity protection. 2003 Wi-Fi Alliance CONFIDENTIAL 23 . it must also report the event to the AP by sending a Michael MIC failure report frame. shall be treated as cause for a MIC failure event. If the device is a Supplicant. Furthermore. request bit. request bit. These failure events are defined as: 1. they are insufficient to detect active attacks.1X EAPOL Key message is used by the Supplicant to report a Michael MIC failure event to the Authenticator.11 data frames. it shall disallow new associations for a period of 60 seconds. 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 . error bit. The first Michael MIC failure must be logged and a timer is initiated to enforce the countermeasures. at the end of the 60 second period. This message is referred to as the Michael MIC failure report frame and is protected with the current PTK to compute an appropriate 802. For a Supplicant: • The number of Michael MIC failures is accrued independent of the particular key context. The frame shall also have the following Key Information bits set to 1:. Wi-Fi Protected Access Version 2. MIC bit. If the MIC failure event is detected by the Supplicant. MIC bit. it shall first send a Michael MIC failure report frame prior to revoking its PTK and disassociation.

Log details of the Michael MIC failure. If the Authenticator is using EAP. the Authenticator shall not log the disassociation as a Michael MIC failure event. the AP shall not update this variable as a result of this action. Informative Note: since an access point may support ciphers other than TKIP. discard the offending frame. initialize the countermeasures timer. this is to prevent denial of service attacks through disassociations. 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. If this is the first MIC failure. 2003 Wi-Fi Alliance CONFIDENTIAL 24 . If the Authenticator is using PSKs. The Authenticator shall disallow associations using TKIP for the duration of 60 seconds. the Authenticator may disassociate all STAs who are employing TKIP while allowing non-TKIP running STAs to remain associated. This will restart the EAP state machine. 3. Wi-Fi Protected Access Version 2. At the end of the 60 seconds. Note that while a Supplicant may disassociate with a reason code of Michael MIC failure. If less than 60 seconds have passed since a previous Michael MIC failure. this step is omitted. transition the state of the Authenticator state machine to State INITIALIZE. • For an Authenticator which detects a Michael MIC failure event: 1.11 state diagram. 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. This effectively disassociates and deletes the PTK for all the STAs. the MIC failure counter and timer may be reset and new associations resume. 5. The GTK must also be revoked.0 – April 29. 4. Informative Note: It is an implementation decision whether an AP will continue to transmit Beacons and Probe Responses during the lock out period. If the failure was in a unicast frame. transition every STA using TKIP (for either unicast or broadcast/multicast frames) in the BSS to State 2 in the 802. The countermeasures used by an Authenticator is depicted in Figure 2 and described below. Increment the MIC failure counter 2. When the STA from which the AP received any previous Michael MIC errors leaves the BSS. and also whether those frames will indicate support for TKIP or not.The aMICFailTime attribute shall contain the sysUpTime value at the time the Michael MIC failure was logged.

delete the PTK (and GTK). to prevent this single frame to force a disassociation at the access point. • 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 Version 2. Disassociate from the AP and wait for 60 seconds before (re)establishing a TKIP association with any AP.Informative Note: since a single multicast frame can trigger multiple Michael MIC Failure reports. initialize the countermeasures timer. Revoke all PTKs and GTK Wait 60 Seconds before allowing TKIP associations Plumb new GTK. Enable associations Continue Figure 2 Authenticator Countermeasures The countermeasures used by a Supplicant is depicted in Figure 3 and described below. the EAPOL MIC Failure report can provide the TSC value detected in the multicast frame in the EAPOL-Key RSC field.0 – April 29. • For a Supplicant which detects a MIC failure event due to a unicast or multicast Michael MIC failure: 1. Discard the offending frame. If less than 60 seconds have passed since a previous Michael MIC failure. Michael MIC Failure Event Received Timer < 60 No Timer = 0 Continue Yes Disassociate all STAs. 3. If this is the first MIC failure. The access point can discard subsequent EAPOL MIC Failure reports if the RSC fields are the same. Send a Michael MIC failure report frame to the AP. Increments the MIC failure counter. 2003 Wi-Fi Alliance CONFIDENTIAL Wi-Fi Protected Access 25 . 2. 4.

13.2 10.3.3.1 10.3 10.1.3.4 10.1 Function This primitive reports that a Michael MIC Failure event was detected.1.1. 3.1 MLME-MichaelMICFailure.2 Semantics of the service primitive The primitive parameters are as follows: MLME-MichaelMICFailure. or another AP. 2003 Wi-Fi Alliance CONFIDENTIAL 26 . Figure 3 Supplicant Countermeasures 3.1.indication 3.13. as it does not contain a MIC.0 – April 29.13.forged.13 Michael MIC Failure Event 3. If the frame was genuine.3.indication { Count } Wi-Fi Protected Access Version 2. 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. The STA may attempt association with this.1.1.

13.13.1.1 MLME-EAPOL.14 3.1. 3.13.14 EAPOL (Michael MIC Failure Report) 10. 2003 Wi-Fi Alliance CONFIDENTIAL 27 .3.1.0 – April 29.14.3.1X EAPOL Key message reporting a detected Michael MIC failure.1 Function 10.2 Semantics of the service primitive This primitive indicates that this EAPOL message shall be confirmed.7 10.1.15 10. 3.3.3.3.Name Count Type Integer Valid Range Description 1 or 2 the current number of Michael MIC failure event 3.1.3.1.request 3.12 3.5 10.1.4 Effect of Receipt The MAC is notified that the Michael MIC failure must be logged and countermeasures enforced.4 Effect of Receipt The SME is notified that the MAC has detected a Michael MIC failure.3.3.13.1.13. The primitive parameters are as follows: MLME-EAPOL.2 Semantics of the service primitive There are no parameters for this primitive 3.1.13.1.9 10.1.1.2.3 When Generated This primitive is generated by the MAC when it has detected a Michael MIC failure.1 Function This primitive reports that a Michael MIC Failure event was detected from another STA.1.request 10.1.14. 3.13 3.2 MLME-MichaelMICFailure.8 10. 3.1.1.1. 3.11 10.3.14.10 10.3 When Generated This primitive is generated by the SME when it has received an IEEE 802.3.1.6 10.3.request { Wi-Fi Protected Access Version 2.13.

1. 3.4 Effect of Receipt The SME is notified that this EAPOL message has been IEEE 802.16 3. This primitive indicates that this EAPOL message has been ACKed by IEEE 802.18 10.confirm 10.1.19 10.1. 3.14. 3.1.3.1X EAPOL Key frame N/A N/A 10.3.1.13.4 Effect of Receipt 10.1.1.4 When Generated This primitive is generated by the MAC when an EAPOL message has been ACKed. Data } Name Source Address Destination Address Data Type MAC address Valid Description Range N/A The MAC sublayer address to which the EAPOL message is being transferred Either an individual or group MAC sublayer entity address t The EAPOL message to be transmitted MAC address IEEE 802. Destination address.0 – April 29.1.3.3.13.3 When Generated This primitive is generated by the SME when an EAPOL message has been ACKed.2 Semantics of the service primitive There are no parameters for this primitive.1.14.11 ACKed.11.14.3.3.1 MLME-EAPOL.3.1 Function The MAC is notified that this EAPOL message must be ACKed.1.1.14.14. Wi-Fi Protected Access Version 2.Source address.20 10. 10.17 3. 2003 Wi-Fi Alliance CONFIDENTIAL 28 .

0 – April 29.Wi-Fi Protected Access Version 2. 2003 Wi-Fi Alliance CONFIDENTIAL 29 .

(Variable padding to ensure MIC is calculated on a multiple of 4-byte words). 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 . The Phase 1 key is initialized when you receive the Add Key from NDIS. That is. 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.0 are referenced to the Authenticator.11 header depending on whether you're sending to or from the AP. This applies independently to both Rx and Tx directions. The two addresses that are MIC'd with the data portion of the MSDU are DA and SA. 5.11i Draft 3.0 – April 29.7 of 802. The pad bytes inserted in the packet on RX are not sent up to Windows with the packet. 10. 7. 4. 9. Note that the DA and SA are in different positions of the 802. the 8 byte MIC is inserted after the last byte of the original payload. The IV inserted into the TX Packet conforms to the coding described in the WPA document. The TKIP Phase 1 calculation uses the Transmitter Address. 8. the first three bytes of IV are from the first three Wi-Fi Protected Access Version 2. That is. 2003 Wi-Fi Alliance CONFIDENTIAL 30 .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 MSDU is padded with a byte of 0x5a and then from 4 to 7 0x00s before calculating the MIC on TX. That is. That is.2 Multicast/Broadcast data packets to AP An AP should drop any data MSDU packets whether multicast/broadcast receiver addresses it receives from stations. The pad bytes above are NOT transmitted with the packet. The TKIP and MIC engines are verified against the test vectors. assuming you initialize the TSC to 0's. and not the TA and RA. 2.3. The MIC is calculated on the MSDU and not the MPDU fragments. In the Client that would be its own address for TX P1k and the AP's Address for RX P1K. which are the ultimate destination and source of the packet. then you need to run the P1K on the 0's TSC before you use the key to generate a per-packet key. assume that Tx MIC and Rx MIC referred to in clause 8. a pad byte of 0x5a and from 4-7 bytes of 0x00 are inserted between the last byte of data and the MIC. On RX. 3. 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.23 of the Pairwise Transient key. 3. 11. 6.

3.2 10.7.0 – April 29.2.2 10.2 11.2 10.1.3. Group Keys created by the AP should have a key ID of 2 or 3.6.11 (including all subsections) 10.3.2 10.0: 11.11i Draft 3.11 1999 Standard per the following clauses from 802.12 (including all subsections) 5 MAC Sublayer Management Updates WPA updates the sublayer management of the original IEEE 802.1 11.1. On the AP the pairwise key assigned to a Client should have a key id of 0.3.3. 4 Layer Management Updates WPA updates the layer management of the original IEEE 802.2 10.3.3.11 1999 Standard per the following clauses from 802.6. 12. 2003 Wi-Fi Alliance CONFIDENTIAL 31 .bytes of the per packet Phase 2 key.3.4 Wi-Fi Protected Access Version 2. the next byte includes the key id and the ext IV bit set.2.3.3. The TSCs are saved in memory and used in LSB to MSB order.1.8.3. 13. and the next four bytes contain the upper four bytes of the TSC.11i Draft 3.0: 10.

11i Draft 3.1 and subclauses of 802.Appendix A: Removed Appendix B: TKIP algorithm reference implementations and test vectors A TKIP reference implementation and test vectors are provided in Annex F. 0x03 -1 0 1 2 3 4 0 Wi-Fi Protected Access Version 2.11i Draft 3. Appendix C: Michael reference implementation and test vectors A Michael reference implementation and test vectors are provided in Annex F. Appendix D: WPA information element reference implementation #include "stdafx.2 and subclauses of 802. uchar oui[4]. uchar length.h> #define uchar unsigned char #define ushort unsigned short #define NONE #define WEP40 #define TKIP #define AESCCMP #define AESWRAP #define WEP104 #define IEEE802_1X #define ELEMENTID 0xdd #define GROUPFLAG 0x02 #define REPLAYBITSSHIFT 2 #define REPLAYBITS struct _IE { uchar Elementid.0.0. ushort version.0 – April 29.h" #include <stdio. 2003 Wi-Fi Alliance CONFIDENTIAL 32 .

0xf2. 0x50.uchar multicast[4]. uchar oui05[4] = { 0x00. 0x00 }. 0x50. int unicastasgroup. int i = 0. uchar oui01[4] = { 0x00. 0x05 }. multicast = TKIP. uchar oui02[4] = { 0x00. void test(struct _IE *IE. struct { uchar oui[4]. char *caps. struct { uchar oui[4]. n. // the rest is variable so need to // overlay ieauth structure }. } auth[1]. 0x04 }. uchar oui03[4] = { 0x00. 0x01 }. 0x50. 0x50. 0x02 }. m.0 – April 29. 0x03 }. 0xf2. 0xf2. int unicast[4]. int length) { uchar oui00[4] = { 0x00. uchar oui04[4] = { 0x00. 0x50. }. ushort ucount. } unicast[1]. int auth[4]. Wi-Fi Protected Access Version 2. 0xf2. 0xf2. j. struct _ieauth *ieauth. 0xf2. int multicast. int replayindex. 2003 Wi-Fi Alliance CONFIDENTIAL 33 . ushort ucount. struct _ieauth { ushort acount. ushort acount. unicast[0] = TKIP. 0x50.

ucount = 1. auth[0] = IEEE802_1X. Wi-Fi Protected Access Version 2. oui01. oui00. oui05. unicast[j++] = TKIP. oui02.oui.oui. else if (!memcmp(IE->multicast. else if (!memcmp(IE->multicast. 4)) multicast = WEP104. 4)) multicast = TKIP. 4)) multicast = AESCCMP. else if (!memcmp(IE->multicast. replayindex = 2. 4)) else if (!memcmp(IE->unicast[i]. } if (IE->length >= 12) { j = 0. 2003 Wi-Fi Alliance CONFIDENTIAL 34 . 4)) multicast = WEP40. for(i = 0. 4)) multicast = AESWRAP. unicast[j++] = NONE. 4) && (IE->version == 1)) { // update each variable if IE is long enough to contain the // variable if (IE->length >= 10) { if (!memcmp(IE->multicast. oui04. unicastasgroup = 0. else if (!memcmp(IE->multicast.0 – April 29. oui03. acount = 1. else // any vendor checks here multicast = -1. i++) { if(IE->length >= 12+i*4+4) { 4)) if (!memcmp(IE->unicast[i]. oui01. (i < IE->ucount) && (j < sizeof(unicast)/sizeof(int)). oui02. // information element header makes sense if ( (IE->length+2 == length) && (IE->length >= 6) && (IE->Elementid == ELEMENTID) && !memcmp(IE->oui.

oui. if(IE->length+2 >= 14+4+(m+n)*4) { 4)) Wi-Fi Protected Access Version 2. 2003 Wi-Fi Alliance CONFIDENTIAL 35 . } m = i. else // any vendor checks here .0 – April 29.oui.oui. j = 0. for(i = 0.oui03. else // any vendor checks here . 4)) else if (!memcmp(IE->unicast[i]. unicast[j++] = AESCCMP. oui04. auth[j++] = IEEE802_1X. (i < ieauth->acount) && (j < sizeof(auth)/sizeof(int)). } ucount = j. } if(j > 0) acount = j. } else break. } n = i. if (IE->length >= 14+m*4) { // overlay ieauth structure into correct place ieauth = (struct _ieauth *)IE->unicast[m].oui. 4)) else if (!memcmp(IE->unicast[i]. i++) { if(IE->length >= 14+4+(m+i)*4) { if (!memcmp(ieauth->auth[i]. oui00. } else break. unicast[j++] = AESWRAP.

0x06. } } } char *cip[] = { "". 0x01. 0x00 }. 0x01. 0x01. 0xf2. 0x00. 0x01. 0x00. " AES-CCMP". uchar test3[] = { 0xdd. 0x06. 0x00.caps = (char *)ieauth->auth[n]. 0x00. 0x00. 2nd unicast ignored and default auth uchar test8[] = { 0xdd. char *aip[] = { "". 0x50. char *cip1[] = { " NONE". 0x50. 0x01. 0x00. 0xf2. 0xf2. 0x00. 0x00 }. 0xf2. 0x0a. "AES-WRAP". 0x00. 0x00. 0x10. " 802. 0x00. 0x50. 0xf2. 0x00. 0x00. 0x50. 0x00. uchar test5[] = { 0xdd. 0x01. // too small . 0x02. " WEP40". 0x00. 0x00. 0x02. 0x00 }. unicastasgroup = (*caps)&GROUPFLAG. 0x01. 0xf2. 0x02 }. uchar test2[] = { 0xdd. “WEP104” }. 0x10. 0x50. 0x50. 0xf2. 0x00. 0x00. 0x01. 0x01. 0x16. 0x01. // unicast count too high. " TKIP".1X" }. uchar test6[] = { 0xdd. 0x00. 0xf2. 0x50. 0x00. 0x50. 0x01. 0x01. 0x01. 0x01. 0x02. 0x01. 0x50. 0x50. 0xf2. 0xf2. " WEP40". 0x50. 0x01. 0x01. 0xf2. 0x00. 0x00. 0x00. 0x01. 0x00. 0x50. 0x00. 0x00. 0x02. 0x00}. 0xf2. 0x03. 0x50. 0x00. 0x18. " TKIP". "AES-WRAP". 0x02. // Various IEs to try above with uchar test1[] = { 0xdd. 0xf2. 0x01. 0x00.oui. 0x01}. 0x00. 0x00. 0xf2. 0x50. 0x01. 0x00. 0x50. 0x50. 0x01. 0x50.0 – April 29. 0x01. 0xf2. 0x1c. 0x00. 2003 Wi-Fi Alliance CONFIDENTIAL 36 . 0x04. 0x01. 0x00. uchar test4[] = { 0xdd. 0xf2. 0x00 }. 0x01. 0xf2. 0x50. " AES-CCMP". 0xf2. 0x50. “WEP104” }. 0x00. 0x50. 0xf2. 0x00. Wi-Fi Protected Access Version 2. replayindex = 2<<((*caps>>REPLAYBITSSHIFT)&REPLAYBITS).ignored uchar test7[] = { 0xdd. 0xf2.

0x50. sizeof(test3). test9. cip[(ucount>3?unicast[3]:-1)+1]. sizeof(test7). i. 0x02.4 and subclauses of 802. uchar *tests[] = { test1. 0x10. int _tmain(int argc. 0x00. 2003 Wi-Fi Alliance CONFIDENTIAL 37 . 0x00}. test3. 0x01. cip1[(ucount>0?unicast[0]:- cip[(ucount>1?unicast[1]:-1)+1]. 0x50. 0xf2. 0x50.0 – April 29. test4. 0x00. testsize[i]). int testsize[] = { sizeof(test1). 0x50. // unicast count past end of IE uchar test9[] = { 0xdd. 0x00}. test7. aip[(acount>2?auth[2]:-1)+1]. 0xf2. 0x50. 0x00. 0xf2. 0x00. 0x01. 0x00. 0x00. sizeof(test4). 0xf2. Wi-Fi Protected Access Version 2.0. unicastasgroup?"Group ":"". sizeof(test6). HMAC_SHA1 and PRF reference A reference implementation and test vectors for HMAC-MD5 are provided in Annex F. 0x01. 0x01. test5.0x00. 0x01. _TCHAR* argv[]) { for(int i = 0. 0x00.11i Draft 3. } return 0. 1)+1].3 and subclauses of 802. test2. 0xf2. sizeof(test9). sizeof(test8). 0 }. 0x50. } Appendix E: HMAC_MD5. cip[(ucount>2?unicast[2]:-1)+1]. test8. 0x50. i++) { test(( struct _IE *)tests[i]. aip[(acount>0?auth[0]:-1)+1]. 0x00. A reference implementation and test vectors for HMAC-SHA1 are provided in Annex F. sizeof(test5). NULL }. cip1[(multicast+1)]. 0x02. sizeof(test2). replayindex). 0xf2. 0x01. aip[(acount>1?auth[1]:1)+1]. test6. 0x00.11i Draft 3. 0x02.0. 0x16. 0x00. tests[i] != NULL. aip[(acount>3?auth[3]:-1)+1]. 0x00. 0xf2. printf("IE %d Multicast%s Unicast%s%s%s%s Auth%s%s%s%s %sReplayIndex %d\n".

2003 Wi-Fi Alliance CONFIDENTIAL 38 . ssidlength+4. digest1). 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. (int)strlen(password).0 – April 29. It is recommended that users enter longer passwords than 8 characters (e. for (i = 0.11i Draft 3. 20 characters or longer).0 with the following changes. (unsigned char *)password.5 and subclauses of 802. digest). } The first call to hmac-sha1 in the reference code should read hmac_sha1( digest.11i Draft 3.8 and subclauses of 802. Add the following as the first executable statements of function F(). (int)strlen(password). Appendix F: ASCII Password reference A reference implementation for ASCII password support is provided in Annex F. The test vectors should read Password=”password” SSID=”IEEE” SSIDLength=4 f42c6fc52df0ebef9ebb4b90b38a5f902e83fe1b135a70e23aed762e9710a12e Password=”ThisIsAPassword” SSID=”ThisIsASSID” SSIDLength=11 0dc0d6eb90555ed6419756b9a15ec3e3209b63df707dd508d14581f8982721af Password=”aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa” Wi-Fi Protected Access Version 2.g.0.A reference implementation and test vectors for PRF are provided in Annex F. A_SHA_DIGEST_LEN. i++) { assert((password[i] >= 32) && (password[i] <= 126)). i < strlen(password). (unsigned char *)password. The second call to hmac-sha1 in the reference code should read hmac_sha1( digest1.

.System Structure Wi-Fi Protected Access Version 2. Client STA “Higher Layer Software” AP “Higher Layer Software” CLIENT STA MAC AP MAC Figure 4 . 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. 2003 Wi-Fi Alliance CONFIDENTIAL 39 .pdf.0 – April 29. so there is no need to repeat that in this description.1X State synchronization This document assumes the synchronisation variables defined in 802-1aa-d4-1.SSID=”ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ” SSIDLength=32 becb93866bb8c3832cb777c2f559807c8c59afcb6eae734885001300a981cc62 Appendix G: IEEE 802. Appendix H: Michael Countermeasures State Machines This appendix describes the state machines for the TKIP Michael MIC Countermeasures.

No MLMEMichaelMICFailure. 2003 Wi-Fi Alliance CONFIDENTIAL 40 .Client STA MAC Part 1 Wi-Fi Protected Access Version 2.State 3 Frame with MIC failure detectTimer running && detectTimer < 60? Yes MLMEMichaelMICFailure .0 – April 29.indication (second) The idea is to speed up transmission of the EAPOL-Key messager that is about to be sent. indication (first) ‘Drop as many frames from the TX queue as possible’ ‘Start 60 second blockingTimeout’ ‘Start detectTimer’ Blocking State 3 Figure 5 .

0 – April 29.Client STA MAC Part 2 Wi-Fi Protected Access Version 2. 2003 Wi-Fi Alliance CONFIDENTIAL 41 .Figure 6 .

2003 Wi-Fi Alliance CONFIDENTIAL 42 .Figure 7 .Client STA Higher Layer Software Wi-Fi Protected Access Version 2.0 – April 29.

AP MAC Wi-Fi Protected Access Version 2.Figure 8 .0 – April 29. 2003 Wi-Fi Alliance CONFIDENTIAL 43 .

probe response. 2003 Wi-Fi Alliance CONFIDENTIAL 44 .0 – April 29.11 MPDUs if fragmentation is not supported De-fragmentation of TKIP data packets Use of integrity check and IV for replay protection Michael Michael counter measures WPA information element in beacon. association/re-association request Privacy bit set in capability information element Beacon/Probe response/association/re-association request 4-way handshake Required Required Required Required Required Required Required/Recommended/Optional Required Optional Required Wi-Fi Protected Access Version 2.Figure 9 AP Higher Layer Software Appendix I: WPA Requirements Function 48 bit TKIP (including phase 1 and 2) Fragmentation of TKIP data packets Note: The station will not be able to send full size 802.

Validation of WPA IE in beacon/probe response/association/re-association request with WPA IE in 4-way handshake Group key update Pairwise Request (with or without error) Group Request (with or without error) Encryption of 802.1X data packets until the correct key is installed. 2003 Required Required Required Required Required Required Required Required Optional for NIC Required Required Recommended Recommended Recommended Required Required for NIC Recommended for AP Required Required Required Required for AP Recommended Optional Required Required Wi-Fi Alliance CONFIDENTIAL 45 . 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 save Saving of IBSS IV Support for RADIUS Group Key Update on a time interval Group key update on a disassociation of a authenticated station Use of PRF for Pairwise key generation Use of PRF for Group Key generation Wi-Fi Protected Access Version 2. (Note: This is Group key for multicast/broadcast from AP or from station if Pairwise key is not installed.0 – April 29.1X messages not encrypted with Group Keys WPA authentication mode WPA-PSK authentication mode WPA-None authentication mode Open 802.1X messages with Pairwise key 802.11 MAC authentication for all WPA authentication modes WPA-PSK ASCII passphrase hash WPA-PSK 256 bit key Non-WPA support Non-WPA and WPA mixed mode Group key cipher Pairwise key cipher No sending of non-802.

2003 Wi-Fi Alliance CONFIDENTIAL 46 .0 – April 29. Wi-Fi Protected Access Version 2.Use of random number on AP for master key for Group Key generation Initialization of Key Counter Initialization of EAPOL-IV from Key Counter Required Required 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.