4 –Way Handshake Synchronization Issue

1. 4 –Way Handshake Synchronization Issue Date: 2010-01-07 Author: Alexander Tolpin, Intel Corporation

2. 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 Alexander Tolpin, Intel Corporation

3. 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 • There are several possible outcomes: • 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 Alexander Tolpin, Intel Corporation

4. 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 Alexander Tolpin, Intel Corporation

5. Recommendation • There are three possible approaches to resolving this issue. • Delay sending encrypted data until both sides have had a reasonable opportunity to update their keys. • Attempt to coordinate the MLME-SETKEYS.requests from supplicant and authenticator based on an event they can both observe • 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. Alexander Tolpin, Intel Corporation

6. 4 pair-wise key exchange – failure sequence NIC AP OS/Supplicant Driver Assoc Completion EAP Auth 1st EAPOL Key 1st EAPOL Key 1st EAPOL Key ACK 2nd EAPOL Key 2nd EAPOL Key 2nd EAPOL Key ACK 3rd EAPOL Key 3rd EAPOL Key 3rd EAPOL Key ACK 4th EAPOL Key 4th EAPOL Key 4th EAPOL Key ACK Long Delay between 4th EAPOL Key and Key’s Update Short Delay Encrypted GRP Key ACK Encrypted GRP Key DROPPED Set of Keys Install Key Request Install Key Complete

7. Data Transfer and key update– failure sequence AP uCode OS/Supplicant Driver 3rd EAPOL Key 3rd EAPOL Key 3rd EAPOL Key ACK Data Data (Old Key) Data (Old Key) 4th EAPOL Key 4th EAPOL Key 4th EAPOL Key ACK Data Data (Old Key) Data (Old Key) Data Data (Old Key) Data (Old Key) Long Delay between 4th EAPOL Key and Key’s Update Data Data (Old Key) Data (Old Key) Data Data (Old Key) Data (Old Key) Dropped due to decryption failure Data Data (Old Key) Data (Old Key) Data Data (Old Key) Data (Old Key) Data Data (Old Key) Data (Old Key) Key install OID Update Key Request Update Key Complete Data Data (New Key) Data (New Key) Data Data (New Key) Data (New Key) Data Data (New Key) Data (New Key) Data Data (New Key) Data (New Key) Data Data (New Key) Data (New Key) Data Data (New Key) Data (New Key)