Hostapd to Wpa_supplicant 4 way Handshake Problem

[Southworth, Damon]

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

>The initial 4-way handshake should be in plain since the PTK is only
set after message 3
>(or well, in theory, message 4 could be encrypted, but it shouldn't be
in the normal case).
>Group Key handshake >(two EAPOL frames after the 4-way handshake) is
encrypted, though
>(or well, again, some implementations do this incorrectly and end up
using unencrypted
>frames..).

Yes, the initial handshake is in the clear, but this in not the one we
are interested in as this is successful. The unsuccessful one comes
later and is encrypted. As we are re-keying every ten seconds to force
the problem there could be tens of re-keys before we capture the failure
within a few minutes. This also becomes a lot of wireless traffic to
sift through as we are also transmitting heavily to force the problem.

>This sounds more complex than it should have been.. Can you see the
unencrypted EAPOL
>frames with EAP negotiation in them and at least messages 1 through 3
of 4-way handshake in
>clear? Feel free to send me a capture log for further analysis if the
handshake frames are not
>easily identified.

I am sure it was, but as only the deauthentication packets are sent in
the clear around the point of the key exchange failure I didn't really
know of any better method at the time. You should be able to easily
reproduce the problem yourself rather than sending you a rather large
wireless capture file.

>This is a known problem, but it hasn't happened that frequently in my
tests, so I haven't been
>too concerned so far. However, it sounds like this is indeed happening
way too frequently in
>your setup for some reason.

Well, I find it easy to reproduce. Set yourself up an access point with
hostapd using a fast re-key, say "eap_reauth_period=10". From the client
connect to the access point and then flood the network interface. The
most successful way I find is to use netcat. Sink a listener to
/dev/null on the access point "nc -l -p <port no> > /dev/null". Flood
traffic from the client "dd if=/dev/zero bs=1M | nc <access point
network address> <portno>. I find the problem occurs rather quickly.

>I'm not very familiar with that code, but that may be more for making
sure that the key
>configuration is atomic operation (i.e., keys do not change in the
middle of a frame
>transmission or between different packets that are being transmitted
during the key update)
>than for avoiding the issue with message 4 of 4-way handshake getting
encrypted.

You are probably correct but as it was stopping the queues I wondered if
it could also guarantee that 4/4 was transmitted before applying the new
key.

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

>MLME-SETPROTECTION.request() primitive is indeed used to first
configure the PTK only for
>receiving > (i.e., the client would be in a state where it can receive
both the encrypted
>Group Key message or >a data frame and unencrypted EAPOL message 3/4,
if re-transmitted).
>RX_TX configuration is enabled only after having finished all initial
key handshakes (i.e.,
>after Group Key handshake in case of WPA and after having processed msg
>3/4 with GTK and transmitted msg 4/4 in case of WPA2). This would
potentially help with
>WPA (but less so with WPA2).

...

>Yes, the client drivers should really support
>MLME-SETPROTECTION.request() primitive and concept of keys being set
for TX-only, RX-only,
>and TX+RX. This would resolve some of the race conditions (both
internal one between
>set-key completing faster than TX and external one with msg 3/4 being
re-transmitted).
>Unfortunately, this type of operation does not really exist in most (if
any) driver interfaces..

So, this would indeed be the correct place to try and attack this race
condition that is causing us the problems at the moment by filling in
the calls in the driver interface and adding suitable support into the
kernel driver. Probably not that easy as you indicate below but at least
a place to focus our efforts.

>Some of the problem cases (the internal race condition) could be
resolved in the driver by
>making sure that all frames that are sent (TX processing started in the
driver) prior to
>set-key operation are sent with the old key (or unencrypted, if no key
was configured)
>and the set-key operation is done with enough barrier both to old and
new TX frames
>(i.e., it is an atomic operation and order with set-key and TX
operations do not change).
>However, this may not be that easy to do for all cases (the madwifi
ath_key_update_being/end may
>handle the barrier part for new frames, but not necessarily for the
last pending frames before
>the set-key operation).

So it sounds like we are looking for a solution to solve the problem of
just how to guarantee the correct sequencing within the driver between
the asynchronous send() of the 4/4 key exchange over the PF_PACKET
socket and the synchronous ioctl call to IEEE80211_IOCTL_SETKEY to place
the key into the hardware. It certainly should be possible, it just
needs suitable driver support.

Regards,
Damon Southworth

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