Hostapd to Wpa_supplicant 4 way Handshake Problem

[Southworth, Damon]

>> 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 used an AirPcap+Wireshark wireless sniffer but as all the packets
are encrypted I was not sure of an easy method or tools to decrypt them.
Wireshark supports PSK WPA decryption but not enterprise. The
deauthenticate packet from the HostAP is sent in the clear so I was
using this as a marker and working backwards using the payload sizes to
try and match up the packets through debug with those being was being
transmitted and received by the drivers. It was a painful task and very
difficult differentiate the key exchange from the data so I didn't feel
I was really getting anywhere with that. My conclusion was that it did
look as though the response was being sent but I couldn't analyse it
contents. I would like to confirm this if you now of a suitable method.

...

>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.

Okay, so it sounds as though this is a known problem without an easy
solution. But as it happens so readily with a reasonable amount of
traffic there must have been some attempts already. I can see that there
is some defensive programming in the madwifi driver around where the
keys are programmed and I was wondering if the
MLME_SET_PROTOTECTION_XXXX calls from wpa_supplicant were also connected
to such a scheme, although as far as I tell none of the driver
interfaces actually implement these methods. I was wondering if a scheme
like the madwifi ath_key_update_begin() where it stops the queues could
be used around the whole key exchange instead (obviously not stopping
the queue for the keys). From your position having written the
supplicants have you in a mind a preferred direction that should be
taken to start to address this weak point? As a side, was this the
reason that WPA2 included the GTK within the 4-way handshake?

Regards,
Damon
----

Teradyne Diagnostic Solutions Limited, Reg. No. 790061 Orion Business Park, Bird Hall Lane, Stockport, SK3 0XG, United Kingdom

Teradyne Diagnostic Solutions GmbH, Reg No. HRB 7844 Adalperostrasse 29, 85737 Ismaning, Germany

Teradyne Diagnostic Solutions Inc., EIN 48-1281865 28970 Cabot Drive, Suite 100, Novi, MI 48377, USA

Teradyne Diagnostic Solutions Belgium
Delta Business Park, Satenrozen 1 B, 2550 Kontich, Belgium