1. doc.: IEEE 802.11-10/0018r0 Submission January 2010 Alexander Tolpin, Intel CorporationSlide 1 4 –Way Handshake Synchronization Issue Date: 2010-01-07 Author:

2. doc.: IEEE 802.11-10/0018r0 Submission January 2010 Alexander Tolpin, Intel CorporationSlide 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

3. doc.: IEEE 802.11-10/0018r0 Submission January 2010 Alexander Tolpin, Intel CorporationSlide 3 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 4 th 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 Problem Statement

4. doc.: IEEE 802.11-10/0018r0 Submission January 2010 Alexander Tolpin, Intel CorporationSlide 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 4 th EAPOL KEY message. Some APs send encrypted traffic 1.5 ms after receiving the 4 th 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 4 th 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

5. doc.: IEEE 802.11-10/0018r0 Submission January 2010 Alexander Tolpin, Intel CorporationSlide 5 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.

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

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