wpa keyhandshake question / bug

[Jouni Malinen]

On Tue, Apr 19, 2005 at 08:10:11PM +0200, Sebastian Weitzel wrote:

> I am investigating a wpa bug together with hostapd (tested mit madwifi 
> but should also apply to others) and serveral types of clients 
> (windows, prism, madwifi). On reauthentication (WPA, EAP-TLS) clients 
> lose connection from time to time, especially when there is traffic 
> between client and ap. I narrowed down the problem into one direction, 
> and I now want to get some feedback here to hopefully solve it soon.

How often does this happen (e.g., percentage of attempts) and how much
other traffic was being transmitted during reauthentication?

> I will refer to the 802.11i-2004 standard to describe my problem.
> On page 89 step 4 of the 4-way handshake is described. When the 
> Authenticator received message 4 it checks some things and then goes to 
> PTKINITDONE and sets new key to the driver. After this a group key 
> handshake should occur.

IEEE 802.11i-2004 does not use Group Key handshake directly after 4-Way
Handshake; this mechanism is only used with WPA.. Are you talking about
WPA or WPA2?

> This does not always work for me. In my scenario the message 4 under 
> some circumstance does not reach the authenticator. One possibility is 
> it is lost on air. Another harmfull possibilty is that the message 4 is 
> already encrypted with the new sta key and is dropped by the MAC layer 
> as crypto error (linux queuing issue maybe, that means the message 4 is 
> stuck in linux queue while the .set_key function allready activated the 
> new key in the driver). In first case a retransmit on mac layer 
> will/should happen?

Yes, the first case should rely on lower layer retransmission. It might
be useful to use a lower transmit rate and larger retry count for EAPOL
frames in order to make them less likely to be dropped.

Unfortunately, sending msg 4/4 has some race condition issues in both
WPA and WPA2. set_key() better not change the before msg 4/4 has been
sent out. If this is happening often, some additional synchronization
would be needed to avoid issues.

> That is the point where I am very confused. Does wpa_supplicant 
> recognize that the message 4 did not arrived at the ap and will 
> retransmit the packet? And whats with the driver interface? If the 
> .set_key function is done (directly after sending message 4) all 
> packets from this time on would be encrypted with the new key and 
> dropped from the ap because the 4-way is not done.

There is no mechanism for wpa_supplicant to know whether msg 4/4 was
sent out correctly or not. Even if there were, it does not really have
many options in fixing the case. Retransmitting the EAPOL message is
done at the lower layer and supplicant is only replying to received
EAPOL frames.

The AP will likely retransmit msg 3/4 if it does not receive msg 4/4.
However, this msg 3/4 is using the old key (or plaintext for the first
4-Way Handshake). Drivers could make this more robust by storing the
previously used key for short period of time after key change and trying
to use it to decrypt packets that fail decryption with the new key. This
would allow the retransmitted msg 3/4 to go through.

-- 
Jouni Malinen                                            PGP id EFC895FA