#7825 BLOC 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:  assigned            
   Priority:  blocker   |   Milestone:  8.2.0 (was Update.2)
  Component:  wireless  |     Version:  not specified       
 Resolution:            |    Keywords:  8.2.0:? relnote     
Next_action:  review    |    Verified:  1                   
  Blockedby:            |    Blocking:                      
------------------------+---------------------------------------------------

Comment(by carrano):

 Replying to [comment:5 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.

 It all makes perfect sense and seems to explain what is happening. What I
 don't get is why 4 and 5 are inverted. Doesn't the standard (802.11i)
 states that the fourth element of the PTK handshake should be sent *after*
 the key is installed? (item "f" bellow)?

 {{{

 The 4-Way Handshake consists of the following steps:
 a) The Authenticator sends an EAPOL-Key frame containing an ANonce.
 b) The Supplicant derives a PTK from ANonce and SNonce.
 c) The Supplicant sends an EAPOL-Key frame containing SNonce, the RSN
 information element from
 the (Re)Association Request frame, and a MIC.
 d) The Authenticator derives PTK from ANonce and SNonce and validates the
 MIC in the EAPOLKey
 frame.
 e) The Authenticator sends an EAPOL-Key frame containing ANonce, the RSN
 information element
 from its Beacon or Probe Response messages, MIC, whether to install the
 temporal keys, and the
 encapsulated GTK.
 f) The Supplicant sends an EAPOL-Key frame to confirm that the temporal
 keys are installed.
 }}}


 Unless...

 I couldn't find the draft 3 of 802.11i (on which TKIP is based) but it may
 be the case that for TKIP, the fourth element is just a regular 802.11 ack
 (type:00/subtype:1101) as some random pages around (including wikipedia)
 seem to imply. If this is the case, this is really an early flaw of that
 draft and will cause this kind of timing issue.

 But...

 If this is not the case, it seems that the supplicant should send the
 fourth frame only after the installation of the key.

 Or...

 Is it the case the once the key is installed the supplicant cannot send a
 non encrypted frame? It doesn't make sense to me.

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