January 2010

doc.: IEEE 802.11-10/0018r0

4 Way Handshake Synchronization Issue

Date: 2010-01-07
Author:
Name
Alexander Tolpin Adrian Stephens

Affiliation Address
Intel Corporation Intel Corporation

Phone

email
alexander.tolpin@intel.com adrian.p.stephens@intel.com

P.O.Box 1659 Haifa +972-4-86531015 Israel 5430

Submission

Slide 1

Alexander Tolpin, Intel Corporation

January 2010

doc.: IEEE 802.11-10/0018r0

Abstract

This presentation describes An issue with the 4 Way Handshake in the current (i.e. Draft P802.11REVmb_D2.0) spec and the consequent failures that are observed in the field A proposed resolution

Submission

Slide 2

Alexander Tolpin, Intel Corporation

January 2010

doc.: IEEE 802.11-10/0018r0

Problem Statement

The completion of 4-way Handshake between STA_I (Authenticator) and STA_P (Supplicant) is not properly synchronized in P802.11REVmb_D2.0. Quotes from D2.0:
The Supplicant uses the MLME-SETKEYS.request primitive to configure the temporal key from 8.5.1 (Key hierarchy) into its STA after sending Message 4 to the Authenticator. The Supplicant sends an EAPOL-Key frame to confirm that the temporal keys are installed.

The timing of the MLME-SETKEYS.request from the supplicant is critical and subject to a race condition with data encrypted using new and old keys STA_I may start the transmission of encrypted frames before STA_P completes updating its keys.
At a result the encrypted traffic will be acknowledged but then dropped and not delivered to upper layers by STA_P

When a 4-way handshake (for re-keying) takes place concurrently with heavy traffic STA_P may send data that are encrypted with the old keys after STA_I has received the 4th EAPOL Key message as confirmation, but before STA_P has actually completed the update of its keys.
At a result the encrypted traffic will be also acknowledge but then dropped and not delivered to upper layers by STA_I If a group key message is lost, STA I cannot receive protected broadcast messages, which may result in further loss of communication and deauthentication Enough data may be lost to disrupt network or application-layer connections Even if connections are not lost permanently, a user-peceived glitch may occur in QoS-sensitive applications
Slide 3 Alexander Tolpin, Intel Corporation

There are several possible outcomes:

Submission

January 2010

doc.: IEEE 802.11-10/0018r0

Actual Field Experience

A widely used OS & Supplicant STA stack sends the Key update message to the driver a few (3-6) ms after sending the 4th EAPOL

KEY message. Some APs send encrypted traffic 1.5 ms after receiving the 4th EAPOL KEY packet at the AP. A STA does not manage to complete key installation so it acknowledges directed encrypted data packets but drops them thereafter. The communication is broken and causes of deauthentication after some timeout. When a 4-way handshake takes place concurrently with with a high rate file copy in 11n, the STA sends tens or hundreds of data frames to AP after sending the 4th EAPOL Key and the AP acknowledges but drops these packets, causing a critical application failure. User experiences and complaints are as follows
STA cannot connect to AP Communication is broken when 4-way handshake takes place during high rate data traffic in 11n

Submission

Slide 4

Alexander Tolpin, Intel Corporation

January 2010

doc.: IEEE 802.11-10/0018r0

Recommendation
There are three possible approaches to resolving this issue.
1. Delay sending encrypted data until both sides have had a reasonable opportunity to update their keys. 2. Attempt to coordinate the MLME-SETKEYS.requests from supplicant and authenticator based on an event they can both observe 3. Modify the protocol to allow two keys to be active during a key handover period.

We propose solution 1, being the simplest one. The following change is proposed in resolution of a comment submitted to LB160

Insert the following new para at 331.20: The Authenticator/Supplicant should postpone the sending of encrypted data after receiving/sending Message 4 for a period of 20 ms.
NOTE--This gives the implementation time to install the new temporal key and avoid transmission of data using a key that has not yet been installed by the peer.

Submission

Slide 5

Alexander Tolpin, Intel Corporation

4 pair-wise key exchange failure sequence

doc.: IEEE 802.11-10/0018r0

OS/Supplicant Driver NIC
AP

Assoc Completion
EAP Auth

1st EAPOL Key 1st EAPOL Key 2nd EAPOL Key 1st 2nd EAPOL Key EAPOL Key ACK 2nd EAPOL Key ACK

3rd EAPOL Key 3rd EAPOL Key 4th EAPOL Key 3rd EAPOL Key 4th EAPOL Key ACK 4th EAPOL Key ACK
Long Delay between 4th EAPOL Key and Keys Update Short Delay

Encrypted GRP Key ACK Encrypted GRP Key DROPPED Set of Keys Install Key Request

Install Key Complete

Submission

Data Transfer and key update failure sequence

doc.: IEEE 802.11-10/0018r0

OS/Supplicant Driver
3rd EAPOL Key Data (Old Key) 4th EAPOL Key Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key) Update Key Request Update Key Complete Data (New Key) Data (New Key) Data (New Key) Data (New Key) Data (New Key) Data (New Key)

uCode
3rd EAPOL Key

AP

3rd

EAPOL Key Data

ACK Data (Old Key) 4th EAPOL Key ACK Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key) Data (Old Key)
Dropped due to decryption failure

4th EAPOL Key Data Data Long Delay between 4th EAPOL Key and Keys Update Data Data Data Data Data Key install OID Data Data Data Data Data Data

Data (New Key) Data (New Key) Data (New Key) Data (New Key) Data (New Key) Data (New Key)

Submission