#7825 NORM 8.2.0 (: can't complete WPA handshake with D-Link WBR-2310

[Zarro Boogs per Child]

#7825: can't complete WPA handshake with D-Link WBR-2310
-------------------------+--------------------------------------------------
   Reporter:  dsd        |       Owner:  jcardona            
       Type:  defect     |      Status:  new                 
   Priority:  normal     |   Milestone:  8.2.0 (was Update.2)
  Component:  wireless   |     Version:  not specified       
 Resolution:             |    Keywords:                      
Next_action:  never set  |    Verified:  0                   
  Blockedby:             |    Blocking:                      
-------------------------+--------------------------------------------------

Comment(by dsd):

 My theory is that we are actually hitting a flaw in WPA combined with some
 slowness of the XO (slow processor, fullmac wifi hardware) and this AP
 being particularly fast.

 The process is normally:

  1. AP sends EAPOL
  1. STA sends EAPOL
  1. AP sends EAPOL
  1. STA sends EAPOL
  1. STA installs PTK
  1. AP sends EAPOL encrypted by PTK

 Steps 1 to 4 are for PTK negotiation. The station actually knows the PTK
 after step 3, but it cannot install it until after (4) because that EAPOL
 is required to be transmitted unencrypted. (this order of operations is
 imposed by wpa_supplicant)

 Here we meet the flaw in WPA: the AP is due to send the the message in (6)
 (first part of GTK transfer) which is encrypted by the PTK, but it does
 not consider if the STA has actually had time to install the PTK - i.e. it
 does not and can not confirm that the STA has had time to complete step
 (5).

 My theory is that the XO then receives the message in (6) but has not had
 time to install the PTK, so decryption fails, and it throws the message
 away. I do not have a way to verify this though, any ideas? Can we ask the
 firmware to provide undecryptable frames to the driver anyway? This would
 at least allow for diagnosis.

 The reason that this happens on this AP and not others is that this AP is
 particularly fast. It takes just 1.83ms to respond to the 4th EAPOL (by
 sending the first GTK EAPOL), whereas other AP's I have looked at take
 over 3ms.

 Possible workarounds:
  1. Modify the firmware to not acknowledge EAPOLs that it can't decrypt.
 The AP would then retransmit the GTK EAPOL, buying us more time to install
 the guy. This is probably not realistic, because decryption probably takes
 too long (you have to send acks very quickly) and assuming any notion of
 design in the firmware, this would be a blatent layering violation...
  1. Make the firmware defer sending the (unencrypted) EAPOL in (4) until
 the PTK has been installed. (messy, but probably the most reliable
 solution if at all possible?)
  1. Make the hardware provide undecryptable EAPOLs to the driver, and let
 the driver fall back on software decrypt to interpret them.
  1. Get all G1G1 users to upgrade to RSN (WPA2), which does not have this
 flaw.

-- 
Ticket URL: <http://dev.laptop.org/ticket/7825#comment:5>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system