Details of Key Derivation for WPA

This section describes the message formats and exchanges that are used in establishing the key hierarchies. In particular, we show the frame format used for the EAPOL-Key frames used in the four-way and two-way exchanges. The details shown here apply specifically to WPA but are basically similar for IEEE 802.11i TKIP and AES as well.

Prior to the key exchanges and temporal key derivation, several things will already have occurred. The access point will have advertised its capabilities and a mobile device will have selected a security method, associated, and initiated an authentication exchange. If upper-layer authentication is in operation, an exchange between the supplicant and authentication server will have completed, resulting in the delivery of a PMK to the access point. The access point will have intercepted an EAP-Success message and delivered it to the supplicant. Receipt of EAP-Success by the access point triggers the four-way key exchange.

In WPA, the key exchange is done using a special variant of the EAPOL-Key message, which is different from that defined in IEEE 802.1X. This variant has some extra fields and is shown in Figure 10.7.

Figure 10.7. WPA Version of EAPOL-Key Descriptor

The descriptor shown in Figure 10.7 appears in the message body section of an EAPOL frame. In practice, it would be preceded by the EAPOL header, as appropriate for IEEE 802.11. The purpose of each field is described in Table 10.1. The most complicated field is Key Information, which is divided into a number of control bits and subfields. Understanding the contents of this field is essential to understanding how the handshake works. The Key Information field is a 16-bit value divided up as shown in Figure 10.8. and described in Table 10.2. The meaning of the control bits 5 through 9 is shown in Table 10.3.

Figure 10.8. Key Information Field

Table 10.1. Fields of the WPA EAPOL-Key Message

Descriptor Type	Unique value (254) that identifies this descriptor as the WPA variant.
Key Information	This field contains several subfields that provide information about the key type and how it should be used. It also contains various control bits to assist in the handshake procedure.
Key Length	The length of the key in bytes. Note in the pairwise key this is the length of the PTK, even though the actual PTK is not sent in a key frame; it is the target key.
Replay Counter	This value is incremented with every message to detect any attempts at replaying an old message. The exception is when this message is in response to an ACK request, in which case the replay value of the message being "ACKed" is inserted.
Key Nonce	Nonce value used to derive temporal pairwise keys or group keys.
EAPOL-Key IV	For group key transfer, the GTK is encrypted using the EAPOL-Key Encryption key in conjunction with this IV value. The encrypted GTK is placed in the Key Data area.
Key Sequence Start	This indicates the value of the sequence number to be expected in the first frame received after the keys are installed. The sequence number protects against replay attacks.
Key Identifier	This is not used in WPA. In the future it might be used to enable multiple keys to be set up in advance.
Key MIC	This is an integrity check value computed across the entire EAPOL-Key frame from the EAPOL Protocol version field to the end of the key material (this field is set to 0 during the computation).
Key Data Length	Defines the length number of bytes in the Key Data field (which might be different from the actual key itself).
Key Data	Material that needs to be sent in secret. For example, in the case of the group key, this is the encrypted value of the GTK. In some pairwise key messages, this carries an information element.

Table 10.2. Key Information Field Summary

Bits 0 3	Currently unused and set to 0.
Bits 4 9	Control bits set at different stages of the handshake.
Bits 10 11	Indicate the key index in the case of group keys. This allows the keys to be updated late by installing new group keys at a different index position to the current operation group key.
Bit 12	Distinguishes between the pairwise and group key messages
Bits 13 15	Indicate the version and allow different schemes and key encryption methods to be used in the future. The value of 001 indicates that: EAPOL MIC is calculated using HMAC-MD5 EAPOL key encryption is done using RC4

Table 10.3. EAPOL-Key Message Control Bits

Request	This bit is used by the supplicant to request that the authenticator initiate a new four-way handshake to refresh the keys.
Error	In TKIP (see Chapter 11), if a MIC failure is detected by a mobile device, a key message is sent with the Error bit set to inform the access point. The Request bit will also be set to request a rekey operation.
Secure	This is set when the four-way key exchange is completed to indicate that the link is now secure.
MIC	This bit is used to indicate when a MIC has been computed for this message and inserted into the MIC field.
ACK	This is set in messages from the authenticator to indicate that it expects a response from the supplicant.
Install	For pairwise keys, this bit indicates that the new key should be installed and put into effect. For group keys, this bit is 0.

The Key Data field is used differently in pairwise and group key handshakes. You might expect that this field would be used to send the actual key to the other party encrypted using the EAPOL-Key Encryption key. This is true in the case of the GTK; however, the pairwise keys are computed independently by the supplicant and the authenticator and are not sent in the key message at all.

In the case of pairwise keys, the Key Data field is used for another purpose. It is used to send a copy of the WPA/RSN Information Element. Information elements in general are described in Chapter 5 and this element in particular is discussed further in Chapter 13. For the moment, just accept that the information element needs to be transferred and that the Key Data field is used for this purpose.

Four-Way Handshake

One of the best ways to understand use of the EAPOL-Key descriptor is to look at a practical example. In the following paragraphs, we follow a four-way handshake.

Message (A): Authenticator Supplicant

At the starting state, no keys are known so the MIC cannot be computed. The authenticator uses this message only to send its value of ANonce to the supplicant. The contents of message (A) are shown in Table 10.4.

Table 10.4. Message (A) Contents

Descriptor type	254
Key Information	Request, Error: 0 Secure: 0 MIC: 0 Ack: 1 Install: 0 Index: 0 Key type: Pairwise Descriptor type: 1
Key Length	64
Replay Counter	<current value>
Key Nonce	ANonce
EAP-Key IV	0
RSC	0
Key Identifier	0
Key MIC	0
Key Data Length	0

• The Error bit is 0 because this is the first message.

• The Secure bit is 0 because the four-way handshake has not completed yet.

• There is no MIC so the MIC bit is 0.

• The authenticator requires the supplicant to send a reply so it sets the ACK bit. If no reply is received after a timeout, the authenticator may resend the message three times before giving up. However, the message should be resent as is, that is, with the same replay field so that, in case the supplicant did receive a previous message, it knows it is a duplicate and not a new message.

• We are not ready to install keys so Install is 0.

• The Index field is not used with pairwise keys.

• The Key Type field indicates "pairwise" and the Descriptor Type field is set to 1.

• The Replay Counter is the value of a counter that is set to 0 when the PMK is first established and is incremented between successive messages.

• The value of ANonce is passed in the Key Nonce field and all the other fields are set to 0. Note that the value of ANonce can't be any old nonce. It has to be selected in a particular way, as described later in this chapter.

• The value of EAP-Key IV is 0 because there is no key data.

• RSC is 0 because the keys are no yet ready for installation.

• Key identifier is reserved and always 0.

Message (A) is sent without any protection. It is not encrypted and there is no MIC. This is the only key message that is ever sent without the MIC bit set to 1 a fact that can be exploited by the supplicant, which should discard the message if any of the fixed fields are different from what has been described here. For example, if the supplicant sees the MIC bit as 0 but the Install bit set, it knows there is foul play.

Given that the supplicant checks the expected fields, an attacker is limited to modifying the Replay Counter or the ANonce fields. Changing the Replay Counter can only result in message rejection and so is pointless. Any changes to the ANonce value will be caught in message (B) because the temporal keys computed by the supplicant from the corrupted ANonce value would be invalid. In such a case message (B) would fail the MIC test and be discarded. Therefore, the fact that message (A) is unprotected does not compromise security.

Message (B): Supplicant Authenticator

After successful delivery of the first message, the supplicant has a copy of ANonce and generates it own value of SNonce. It is then able to compute the transient key. Next, it prepares to send message (B) to the authenticator. This message contains a MIC value and thus proves that the supplicant knows the PMK. The fields for message (B) are shown in Table 10.5.

Table 10.5. Message (B) Contents

Descriptor type	254
Key Information	Request, Error: 0 Secure: 0 MIC: 1 Ack: 0 Install: 0 Index: 0 Key type: Pairwise Descriptor type: 1
Key Length	64
Replay Counter	From rcvd Key Message
Key Nonce	SNonce
EAPOL-Key IV	0
RSC	0
Key Identifier	0
Key MIC	MIC Value
Key Data Length	Length of Key Data
Key Data	Information Element

• The Error field is 0 because there was no MIC value on the previous frame (therefore MIC failure is impossible).

• The Secure field remains 0 until the end of the four-way handshake.

• The MIC field is 1 to indicate that a MIC value has been computed and attached to this message.

• This message is in response to the ACK bit, which was set in message (A). Therefore the ACK bit in this message is clear.

• Install is set to 0 because the keys are not agreed on yet.

• Index is not used.

• Key Type indicates pairwise.

• Descriptor type is 1.

• The Replay Counter in this message should be set to the same value as the counter sent in message (A). This is because it is a response to the ACK bit in message (A). Any other value should be rejected by the authenticator.

• The value of SNonce is sent in the Key Nonce field. This value is needed by the authenticator to compute its copy of the temporal keys.

• The MIC value is placed in the Key MIC position.

• This frame contains unencrypted Key Data. This is the information element that was used to negotiate the security parameters during the association phase. Inclusion of the element here prevents a rogue mobile device from switching security parameters after the initial negotiation. More information about the information element is given in Chapter 13. The data is not encrypted because the IE was sent in the open during association and is not a secret; however, it is protected by the MIC field and cannot therefore be altered.

The fact that the descriptor type field is 1 indicates that the MIC value should be computed using an algorithm called HMAC-MD5, which produces a 16-byte MIC value. The MIC calculation is performed over more the just message (B). It includes all the bytes from the EAPOL protocol version field in the header up to and including the Key Data.

A Note on HMAC-MD5

MD5 is a Message Digest algorithm it takes a message of arbitrary length and produces a 128-bit value called a message digest. It doesn't matter how long the input message is, the digest is always 128 bits. Different input messages could produce the same message digest. However, the algorithm is such that you cannot work in reverse: given a 128-bit digest, you cannot compute a message that would produce that value when processed. Therefore publishing the digest gives nothing away about the message. MD5 is documented in RFC 1321.

To apply MD-5 to actual messages for the purpose of a MIC, MD-5 is used with Hash Message Authentication Code. HMAC as defined in RFC 2104.

To compute the MIC, the supplicant needs to use the newly computed temporal keys. In fact this will be the first use of the keys. If the supplicant does not know the correct PMK, it cannot produce a MIC value that will correspond to the expected result. So the MIC in this message achieves two things: It prevents tampering with the message and it proves that the supplicant knows the PMK.

Message (C): Authenticator Supplicant

When message (B) is received by the authenticator, it is able to extract the value of SNonce because the message is unencrypted. The authenticator then has all the information to compute its copy of the temporal keys. After this is done, the pairwise key distribution is effectively complete. However, the remaining message exchanges, messages (C) and (D), are used to ensure that the keys are put into effect in a synchronized way. Message (C) serves two functions. First, it verifies to the supplicant that the authenticator knows the PMK and is thus a trusted party. Second, it tells the supplicant that the authenticator is ready to install and start using the data encryption keys. The authenticator does not actually install the keys until after it has received message (D). Note that if a retransmission of message (C) is needed due to failure to get a response, the retransmission should be a copy of the original (unencrypted) transmission. The format of message (C) is shown in Table 10.6.

The MIC bit is set and a corresponding MIC value added. The ACK bit is set to indicate a response is required. The value of ANonce is included for reference; although this serves no purpose at this point, it can be used as a check to ensure that this is part of the same four-way handshake.

Table 10.6. Message (C) Contents

Descriptor type	254
Key Information	Request, Error: 0 Secure: 0 MIC: 1 Ack: 1 Install: 0 Index: 0 Key type: Pairwise Descriptor type: 1
Key Length	64
Replay Counter	<Current Value>
Key Nonce	ANonce
EAPOL-Key IV	0
RSC	Starting Sequence Number
Key Identifier	0
Key MIC	MIC Value
Key Data Length	Length of Key Data
Key Data	Information Element

In this message the RSC is used to inform the mobile device of the starting sequence number the access point intends to use. Normally, this would be 0. The Key Data field is used to send a copy of the IE that the access point used in negotiating security during the association phase.

Assuming no retransmit is required, this is the last unencrypted message sent by the authenticator during the life of these pairwise keys. All subsequent messages are encrypted and protected using the temporal data keys.

Message (D): Supplicant Authenticator

This final message verifies to the authenticator that the keys are about to be installed. The settings in the message are shown in Table 10.7.

There is nothing surprising or new in the settings for this message, which is similar to message (B) but without the Key Data field. The Secure bit is not set until the four-way handshake has successfully completed and both supplicant and authenticator have installed the keys. This does not happen until message (D) has been received and decoded successfully. Once this has happened, the authenticator is in a position to deliver the group keys. Note that the Key Sequence Start field indicates to the authenticator the sequence number of the first frame the supplicant intends to send.

Table 10.7. Message (D) Contents

Descriptor type	254
Key Information	Request, Error: 0 Secure: 0 MIC: 1 Ack: 0 Install: 1 Index: 0 Key type: Pairwise Descriptor type: 1
Key Length	64
Replay Counter	From rcvd Key Message
Key Nonce	SNonce
EAPOL-Key IV	0
RSC	Starting Sequence Number
Key Identifier	0
Key MIC	MIC Value
Key Data Length	0

Group Key Handshake

After the complexities of the pairwise key exchange, which had to start off with no security in place and build up step by step, the group key delivery is relatively simple. Basically, there are only two messages. The first sends the key and the second acknowledges that the keys are installed. As explained earlier, there is no key synchronization message because the mobile device is able to store more than one group key at a time and the access point can select the key used on a message-by-message basis. Therefore, as long as the access point knows that a new key has been installed, it can start using it at any time in the future; typically, this is after all the other mobile devices have been updated.

The group key is sent in an EAPOL-key message, which we will call message (a). This has the same format as for pairwise keys. However, an important difference is that the Key Data field is used to send the GTK. The fields for the first group key message are shown in Table 10.8.

Table 10.8. Group Key Update

Descriptor type	254
Key Information	Request, Error: 0 Secure: 1 MIC: 1 Ack: 1 Install: 1 Index: nn Key type: Group Descriptor type: 1
Key Length	32
Replay Counter	<Current Value>
Key Nonce	GNonce
EAPOL-Key IV	IV for encryption of Key Data
RSC	Sequence number of the last encrypted group message
Key Identifier	0
Key MIC	MIC Value
Key Data Length	32
Key Data	<encrypted GTK>

Note that the Secure bit is set because the group key exchange occurs after the pairwise keys are established. The MIC is set (and included) and the ACK bit indicates a reply is required. For the Group Key message the Install bit is set. The Index field is important in the group key message. These two bits indicate which key location should be used to store the new key. For smooth updates, the Key ID index value will not be the value currently in use.

The value of GNonce is included for reference. GNonce is a nonce value selected to derive the GTK from the GMK. The supplicant does not actually need to know this value because the key derivation is done by the access point and not by the mobile device, but it is sent anyway for reference.

Finally, the actual GTK is sent, encrypted with the EAPOL Encryption key that was created as part of the pairwise key handshake. For descriptor type 1, the key is encrypted using RC4 stream cipher^[7] after discarding the first 256 bytes of the RC4 cipher stream output. No padding is added so 32 bytes of GTK produces 32 encrypted bytes, which are placed directly into the EAPOL-Key message.

^[7] See Chapter 6 on WEP and Chapter 11 on TKIP for more information on RC4.

When it is filled out, message (a) is sent to the mobile device, which can decrypt the GTK and install it at the appropriate Key ID index. It then replies with an acknowledge message, message (b), which has the same as for pairwise message (D) except that the Secure bit is set and the Type bit indicates Group.

As a last point, it is expected that the group keys will be updated fairly regularly. For example, they should be updated when a mobile device leaves the network. Also they should be updated if a MIC failure occurs when decoding a multicast. Key updates can occur at any time simply by the access point initiating a group key update frame by sending message (a). However, they can also be requested by a mobile device. In this case the mobile device should send message (b) to the access point with the ACK bit set. This causes the access point to create a new GTK and distribute it to every device (one at a time).