Hostapd to Wpa_supplicant 4 way Handshake Problem

[Jouni Malinen]

On Thu, Jul 31, 2008 at 02:10:36AM +0100, Southworth, Damon wrote:

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

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

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.

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

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.

> I can see that there
> is some defensive programming in the madwifi driver around where the
> keys are programmed

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.

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

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

It may not be easy to extend that over longer period of time. Anyway, it
could also cause problems since the PTK may actually be needed
immediately for decrypting data frames.

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

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

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

I don't remember the discussions in IEEE 802.11 TGi on the topic of
initial GTK being moved into the initial 4-way handshake. However, I
would assume this was mostly to optimize speed (and minimize latency) of
the handshake to avoid gaps when moving between APs.

-- 
Jouni Malinen                                            PGP id EFC895FA