hostapd: 4-way handshake and replay counter handling?

Jouni Malinen j
Sat Oct 15 07:17:03 PDT 2011

On Fri, Oct 07, 2011 at 02:50:10PM +0200, Helmut Schaa wrote:
> I can sometimes reproduce a 4-way handshake failure with an
> Apple iPhone STA and hostapd as authenticator. Under special
> circumstances the iPhone just ignores message 3/4 and thus the
> 4-way handshake times out.

Is this with RSN (WPA2) or WPA? How easily can you reproduce this? Does
iPhone manage to connect to the network automatically after this failure
or is some user action needed to recover?

> The message exchange looks like this (I can also provide the pcap
> if anyone is interested, just need to trim it first):

I would appreciate seeing a capture file for this type of issues. This
is an unfortunately complex area to handle since there are so many
differently broken implementations out there..

> So, the iPhone acks the 3/4-messages just fine but ignores them
> for whatever reason. The order is a bit strange due to the unusual
> retry of the msg 2/4 which was triggered by loads of traffic on the
> channel.
> So, in short, hostapd used the first msg 2/4 it received from the iPhone
> while the iPhone expected us to use the second msg 2/4 which was the
> reply to our second msg 1/4. Since the iPhone used a different nonce
> for the second msg 2/4 that might explain why it is rejecting the msg 3/4.

Yes, if the authenticator and supplicant end up using different SNonce,
message 3/4 will be dropped due to mismatch in the MIC. wpa_supplicant
tries to avoid this by not changing SNonce within a connection attempt
(i.e., it gets changed only on reassociation or after message 3/4 has
been accepted). I think this would be the best approach to use on a
station, but well, obviously hostapd needs to try its best even if the
station does not do that.

> >From IEEE 802.11-2007 (page 213):
> "On reception of Message 2, the Authenticator checks that the key replay
> counter corresponds to the outstanding Message 1. If not, it silently discards
> the message."
> Hence, shouldn't hostapd just discard the first msg 2/4 it receives
> from the STA?

Well, yes, in theory.. However, this is problematic because doing so can
break interoperability with some deployed stations.

> As far as I could see this behavior was introduced in commit
> 22a299ee9d192d06c235428d017234539fbf6a62 ("Improve EAPOL-Key
> handshake stability with retransmitted frames").

Some high load cases require more time to be allowed for the supplicant
to reply to the 4-way handshake messages. This change tries to work
around those situations. The commit log seems to be talking mainly about
group key updates, so it could be possible to have different behavior
for the initial 4-way handshake. However, I'm a bit hesitant on changing
anything in this area because that result in re-introducing issues seen
with other stations in the past.. I.e., this is likely to end up being a
compromise that tries to avoid worst issues.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list