Dealing with bad EAPOL 4/4 messages

[Jouni Malinen]

On Wed, Jan 25, 2017 at 07:47:41AM -0800, Ben Greear wrote:
> While testing my eapol corruptions patch, I noticed this behaviour:
> 
> station sends corrupted 4/4 EAPOL msg
> AP appears to reject it, sends new 3/4 msg to station.
> 
> But, when STA tries to resend 4/4, it seems the driver (or firmware, specifically)
> still has an encryption key set, and for ath10k, that causes a corrupted 4/4 on
> the air.  I am not sure if this is just a CT ath10k firmware issue or not...so:

How did the station receive the retransmitted EAPOL-Key msg 3/4 in such
a case? It would be unencrypted while the STA had already configured TK
and should be dropping all unencrypted frames at that point..

> What is expected behaviour in the case where the 4/4 is rejected by the AP?

The TK should really be configured at first for receive-only and only
once the 4-way handshake has been confirmed to have completed (e.g., AP
sends an encrypted frame), the TK would be enabled for TX. In other
words, msg 4/4 needs to go out unencrypted even when it is sent for the
second time assuming msg 3/4 needed to be retried.

> Should the supplicant clear the key, resend 4/4, and then re-apply the key?

Well.. If the driver were to behave, msg 3/4 would not have even been
received here, so this should not really be a case that would need to be
thought about.. In practice, there are multiple different approaches
vendors have used for this area since there are not really many (if any)
actual implementations that support the separate RX-only, TX-only, and
both cases for keys. Some drivers handle this internally by sending out
EAPOL-Key msg 4/4 without encryption if no properly encrypted frames
have been received from the AP.

That said, please note that whatever design done here needs to also work
for the PTK rekeying case where the recovering of falling back to
unecrypted version is not the correct thing to do.. There, the correct
behavior would be to use the previous TK.

I don't think this can be fixed cleanly with wpa_supplicant changes
only. So far, it looks like there has not been sufficient justification
to get anyone working on providing more complete kernel interface for
addressing this potential "race condition" cleanly. This is not exactly
a new issue, i.e., this has been known for more than ten years..

> Does it do that now?

No. Clearing the TK would be incorrect to do here and could result in
new issues, e.g., when the AP manages to process the EAPOL-Key msg 4/4
after having already sent another 3/4. This can happen if the AP has a
short timeout for the first retry and STA takes some time to process the
3/4 and needed key operations. There are so many different ways of
getting into problems here (especially the PTK rekeying cases are
horribly complex for retries..) that this cannot really be worked around
from wpa_supplicant.
 
-- 
Jouni Malinen                                            PGP id EFC895FA