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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
