Hostapd to Wpa_supplicant 4 way Handshake Problem

[Jouni Malinen]

On Tue, Jul 29, 2008 at 10:05:45AM +0100, Southworth, Damon wrote:

> I started to dig into the problem and found that these
> de-authentications were happening during the 4-way handshake, in
> particular during the 3/4 and 4/4 exchange where the new pair wise keys
> are passed to the driver.

..

> This shows that the AP did not receive the 4/4 packet and so went into
> retry before giving up. However, on the STA side we see that it has
> received 3/4 and replied with 4/4.

Have you used a wireless sniffer to look at what exactly is sent here?
It looks like the AP does not receive msg 4/4 for some reason, so I
would like to make sure that a proper EAPOL-Key message is indeed send
by the client and acknowledged by the AP.

> I have looked at the code it can be seen that the new PTK is installed
> straight after the 4/4 is sent, so if 4/4 is lost am I correct that in
> the above situation 3/4 retries can't be received as the new keys have
> been already been installed on the STA?

It depends.. There are number of unfortunate race conditions in the
4-way handshake design and the exact behavior of the driver in this type
of case. Some drivers may end up allowing the unencrypted retransmission
of msg 3/4 to go through even if the pairwise keys were set.

> I noticed that the problem was exacerbated by heavy traffic on the link.
> The 4/4 send is using the sendto() call in function l2_packet_send() in
> module l2_packet_linux.c. As far as I know this socket call returns as
> soon as the packet has been accepted by the network stack. Can it be
> guaranteed that this packet is transmitted before the keys are installed
> or is there a possibility for the keys to be installed before the
> transmission takes place causing it to be incorrectly encrypted and not
> received by the AP?

Unfortunately, there is no such guarantee and no easy way of
implementing this. It would be nice to be able to use a TX status
callback to at least verify that the msg 4/4 was acknowledged (even
though this itself does not really guarantee that it was processed
correctly). In addition, it would be useful to allow unencrypted msg 3/4
even at this point to work around this potential race condition.

-- 
Jouni Malinen                                            PGP id EFC895FA