race condition in wpa_supplicant?
Lohmann, Peter
plohmann
Thu Feb 7 11:05:13 PST 2008
While investigating a failure to authenticate using the wpa_supplicant (5.8), using WPA-PSK, we came accross the following.
In WPA-PSK TKIP mode, there are a number of temporal keys that are created and updated as the system is running. Both the STA (station) and the AP (access point) create Pairwise Transient Keys (PTK) that are unique for that
STA-AP connection. Likewise, the AP creates a Group Transient Key (GTK) for multicast or broadcast messages from the AP.
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.
The fourth message of the 4-way handshake is an ACK originating from the STA, telling the AP that it received the PTK and MIC. Once this ACK is received from the STA, the AP sends out the 2-way GTK handshake (with the
key material (PTK) acknowledged by the STA).
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 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.
Are we misunderstanding the 4-way handshake protocol and how a WLAN driver/wpa_supplicant is supposed to handle this?
Thanks,
-- Peter
More information about the Hostap
mailing list