hostapd: 4-way handshake and replay counter handling?

[Helmut Schaa]

On Sat, Oct 15, 2011 at 4:17 PM, Jouni Malinen <j at w1.fi> wrote:
> 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?

RSN.

> How easily can you reproduce this?

Reproducibility is low, maybe one out of 30 tries while constantly generating
traffic on the channel with a second client.

> Does
> iPhone manage to connect to the network automatically after this failure
> or is some user action needed to recover?

The iPhone had a different network configured during that time and
connected to that one instead. Not sure how it would have behaved if
there wasn't a different network around.

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

See private mail.

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

Hmm, ok, sounds like there are lots of strange client implementations out
there :)

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

Understood. And I just realized I didn't have "Work around SNonce updates
on EAPOL-Key 1/4 retransmission" applied. The longer timeout might have
helped in this case too I guess. So, I'll try with that patch applied again ...

Thanks so far,
Helmut