Hostapd to Wpa_supplicant 4 way Handshake Problem
Jouni Malinen
j
Wed Jul 30 05:39:45 PDT 2008
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
More information about the Hostap
mailing list