4 way handshake synchronization issue
Download
1 / 7

4 –Way Handshake Synchronization Issue - PowerPoint PPT Presentation


  • 589 Views
  • Updated On :

4 –Way Handshake Synchronization Issue. Date: 2010-01-07. Author:. 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. Problem Statement.

Related searches for 4 –Way Handshake Synchronization Issue

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '4 –Way Handshake Synchronization Issue' - chibale


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
4 way handshake synchronization issue l.jpg
4 –Way Handshake Synchronization Issue

Date: 2010-01-07

Author:

Alexander Tolpin, Intel Corporation


Abstract l.jpg
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


Problem statement l.jpg
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


Actual field experience l.jpg
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


Recommendation l.jpg
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


Slide6 l.jpg

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


Slide7 l.jpg

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)


ad