Dealing with bad EAPOL 4/4 messages

[Ben Greear]

On 02/05/2017 11:39 AM, Jouni Malinen wrote:
> 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..

I think I hit this while testing my supplicant patch that corrupts the 4/4 response,
so local driver thinks it is OK, but remote AP will drop it because it is corrupted.

ath10k enables the key as soon as the 4/4 is sent, and does not wait for
decoding a received frame.  There is only one key used for tx and rx, so
no way to just set rx and not tx key.

I think I will not worry about trying to fix this properly.  It would take a lot
more RAM in the ath10k firmware to have two sets of keys (and might have other bugs as
well, for all I know).

The station does recover by re-associating a bit later.

Thanks for the detailed answer.

--Ben

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

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com