race condition in wpa_supplicant?

[Jouni Malinen]

On Thu, Feb 07, 2008 at 11:05:13AM -0800, Lohmann, Peter wrote:

> The PTK keys are created with a 4-way handshake in the clear.  The GTK is then sent with a 2-way handshake using the PTK keys.  The way most APs work, they send the initial 4-way handshake and then follow it immediately with a
> 2-way handshake to update the GTK.

This is the case for WPA. WPA2 (IEEE 802.11i) combines the initial GTK
delivery into the 4-way handshake.

> The wpa_supplicant sends the fourth 4-way message *before* it tells the driver to update its key material.  We're not sure why because these messages are sent in the clear.  So, if the AP sends a 2-way GTK message (which is not in the clear), *before* the driver has a chance to send the new key material to the WLAN HW, the 2-way GTK
> Handshake will *never* be seen by the driver because the WLAN HW will simply discard it (because of wrong key material).  Adding alot of debug spew to the WLAN driver changes the timing an causes authentication to succeed.

This is an unfortunate race condition in the protocol design and the
order in wpa_supplicant is a workaround for allowing the drivers to send
out msg 4/4 unencrypted and then configure keys as soon as possible
after that for the group key handshake.

The group key handshake (msg 1/2) is supposed to be retransmitted
couple of times which should be enough to handle this issue in most
cases.

> This can be fixed if, when the driver receives the 4th 4-way ACK message, it simply saves it (without sending it) and waits for the wpa_supplicant to then provide the new key material.  Once the key material has been accepted by the WLAN HW, the saved 4th 4-way ACK message is sent to the AP.  

That would be one way of improving the likelihood of not hitting this
issue. However, it is not a complete solution. If the msg 4/4 is lost
(i.e., AP does not receive it), msg 3/4 is retransmitted and the client
would have keys configured at this point..

The most robust solution for this would be to configure the keys in two
phases. When wpa_supplicant receives msg 3/4, it would derive PTK and
configure the key only for receive (i.e., ready for receiving group key
msg 1/2) and only after this, the msg 4/4 would be transmitted. The key
could then be enabled for transmit when receiving group key msg 1/2
(i.e., to allow the possible retransmissions of msg 3/4 to be processed
and replied to with an unencrypted frame).

One problem here is that most drivers do not support separate
configuration of keys for TX, RX, both..

-- 
Jouni Malinen                                            PGP id EFC895FA