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

Wi-Fi Protected Access Version 2.0 – April 29, 2003 Wi-Fi Alliance CONFIDENTIAL 2

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


APPENDIX J: SUGGESTIONS FOR RANDOM NUMBER GENERATION 46


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.


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


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.


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


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.


Network Type

Authentication mode or authenticated key management

Encryption status

Manual Key required?

802.1X enabled?

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.


• 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


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.


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


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.

Remove PTKRemove GTK(1..2)802.1X::portControl = ForceAuthorized;GTK = PSK;SetGTK(1, Tx/Rx, GTK);802.1X:VirtualPort = True802.1X::VirtualSecure = True802.1X::portMode = Enabled;

GLOBALPSK

PSK &&!AuthenticationServerSystem

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.


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.


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.


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

Message 2: MIC = 1, ACK = 0, 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.


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.


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.


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.


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.


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”.


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


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.


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.


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 MICFailure Event

Received

Timer < 60

Disassociate allSTAs, Revoke allPTKs and GTK

Wait 60 Secondsbefore allowing

TKIP associations

Timer = 0 Continue

Plumb new GTK,Enable

associationsContinue

Yes

No

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


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.

Send Michael MICFailure Report

frame

Timer < 60

Stop Receiving Class 3 framesEnsure Michael MIC Failure Report frame was sent

Disassociate from AP

Wait 60 secondsbefore associating

with TKIP

Timer = 0 Continue

Continue

Yes

No

Michael MIC FailureEvent from a received

frame

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

}


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.

3.1.9 10.3.13.1.2 Semantics of the service primitive 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.

3.1.11 10.3.13.1.4 Effect of Receipt 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.

3.1.15 10.3.14.1.2 Semantics of the service primitive The primitive parameters are as follows:

MLME-EAPOL.request {


Source address,

Destination address,

Data

}

Name Type Valid Range

Description

Source Address

MAC address N/A The MAC sublayer address to which the EAPOL message is being transferred

Destination Address

MAC address N/A Either an individual or group MAC sublayer entity address t

Data IEEE 802.1X EAPOL Key frame

N/A The EAPOL message to be transmitted

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

3.1.16 10.3.13.1.4 Effect of Receipt 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.

3.1.19 10.3.14.1.2 Semantics of the service primitive 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.

3.1.20 10.3.13.1.4 Effect of Receipt The SME is notified that this EAPOL message has been IEEE 802.11 ACKed.


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


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


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 subclauses of 802.11i Draft 3.0.

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;


uchar multicast[4];

ushort ucount;

struct {

uchar oui[4];

} unicast[1]; // the rest is variable so need to

// overlay ieauth structure

};

struct _ieauth {

ushort acount;

struct {

uchar oui[4];

} auth[1];

};

int multicast;

int unicast[4];

ushort ucount;

int auth[4];

ushort acount;

int unicastasgroup;

int replayindex;

void test(struct _IE *IE, int length)

{

uchar oui00[4] = { 0x00, 0x50, 0xf2, 0x00 };

uchar oui01[4] = { 0x00, 0x50, 0xf2, 0x01 };

uchar oui02[4] = { 0x00, 0x50, 0xf2, 0x02 };

uchar oui03[4] = { 0x00, 0x50, 0xf2, 0x03 };

uchar oui04[4] = { 0x00, 0x50, 0xf2, 0x04 };

uchar oui05[4] = { 0x00, 0x50, 0xf2, 0x05 };

int i = 0, j, m, n;

struct _ieauth *ieauth;

char *caps;

multicast = TKIP;

unicast[0] = TKIP;


ucount = 1;

auth[0] = IEEE802_1X;

acount = 1;

unicastasgroup = 0;

replayindex = 2;

// information element header makes sense

if ( (IE->length+2 == length) && (IE->length >= 6)

&& (IE->Elementid == ELEMENTID)

&& !memcmp(IE->oui, oui01, 4) && (IE->version == 1)) {

// update each variable if IE is long enough to contain the

// variable

if (IE->length >= 10) {

if (!memcmp(IE->multicast, oui01, 4))

multicast = WEP40;

else if (!memcmp(IE->multicast, oui02, 4))

multicast = TKIP;


multicast = AESCCMP;


multicast = 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;



unicast[j++] = AESCCMP;


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) {


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



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.


A reference implementation and test vectors for PRF are provided in Annex F.5 and subclauses of 802.11i Draft 3.0.

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=4f42c6fc52df0ebef9ebb4b90b38a5f902e83fe1b135a70e23aed762e9710a12e

Password=”ThisIsAPassword” SSID=”ThisIsASSID” SSIDLength=110dc0d6eb90555ed6419756b9a15ec3e3209b63df707dd508d14581f8982721af

Password=”aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”


SSID=”ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ” SSIDLength=32becb93866bb8c3832cb777c2f559807c8c59afcb6eae734885001300a981cc62

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. .

Figure 4 - System Structure

Client STA “Higher Layer

Software”

CLIENT STA MAC

AP “Higher Layer

Software”

AP MAC


No

Yes

‘Start detectTimer’

‘Drop as manyframes from the TXqueue as possible’

Frame withMIC failure

MLME-MichaelMICFailure.

indication (first)

MLME-MichaelMICFailure

.indication(second)

State 3

State 3

detectTimerrunning &&detectTimer

< 60?

Blocking

‘Start 60 secondblockingTimeout’

The idea is tospeed up

transmission of theEAPOL-Key

messager that isabout to be sent.

Figure 5 - Client STA MAC Part 1


Blocking

MLME-EAPOL.request

Send frame

MLME-EAPOL.con

firm

Blocking

MLME-DISASSOCIATE

.request

‘Carry outdisassociation’

MLME-DISASSOCIATE.confirm

Blocking

BlockingTimeout

MLME-ASSOCIATE

.request

MLME-ASSOCIATE

.confirm(Michaelfailure)

State 2

Received dataframe

Blocking

MA-UNITDATA.req

uest

StillAssociated?

No

Waiting ForDissassociation

MLME-DISASSOCIATE

.request

‘Carry outdisassociation’

MLME-DISASSOCIATE.confirm

State 2

Yes

Note that this isrejecting theassociation

Figure 6 - Client STA MAC Part 2


MLME-MichaelMICfailure.indication (count)

MLME-EAPOL.request

(EAPOL-Key with MICfailure report) TO AP

Count =2?

yes

Wait for framestatus

Normal

No

Normal

MLME-EAPOL.confirm

MLME-DISASSOCIATE

.request

Wait fordisassociation

confirm

Note that thisframe must begiven a correct

LLC/SNAP headerdespite apparentlyavoiding the LLC/

SNAP layers

Figure 7 - Client STA Higher Layer Software


NoYes

‘Start thedetectTimer’‘Disassociate all

STAs. All RX & TXdata should be

dropped’

Frame withMIC failure

NormalOperation

NormalOperation

detectTimerrunning &&less than

60?

MLME-MichaelMICFailure.

request

‘Start 60 secondblocking timeout’

Blocking

Blocking

MA-MichaelMICFailure.

request

Blockingtimeout expired

Normal Operation

AssociationRequest

Frame fromSTA

Disassociationframe (MIC

failure) to STA

Note that all STAsare disassociated,so all data trafficwill be dropped

Figure 8 - AP MAC


*

EAPOL-Key withMIC failureindication

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

Note: The station will not be able to send full size 802.11 MPDUs if fragmentation is not supported

Optional

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 response, association/re-association request

Required

Privacy bit set in capability information element Beacon/Probe response/association/re-association request

Required

4-way handshake Required


Validation of WPA IE in beacon/probe response/association/re-association request with WPA IE in 4-way handshake

Required

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 authentication modes

Required

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 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)

Required

Queuing of EAPOL-Key messages when in power save

Required

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 authenticated station

Optional

Use of PRF for Pairwise key generation Required

Use of PRF for Group Key generation Required


Use of random number on AP for master key for Group Key generation

Required

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.

WPA WPA Eap Artikel Revised de Rev2

Documents

Transcript of WPA WPA Eap Artikel Revised de Rev2