The following situation was mentioned a few times here, but I want to discuss it a bit further. Situation: client sends EAPOL msg 4/4 but the AP does not receive it properly. This will cause the AP to retransmit 3/4 without link-layer encryption. The client processes this frame, and replies with an encrypted 4/4. The AP drops the retransmitted 4/4 because it hasn't yet configured keys. > 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.. Linux allows unencrypted EAPOL frames, even if keys have been set. See the function ieee80211_frame_allowed: http://lxr.free-electrons.com/source/net/mac80211/rx.c#L2166 So the client will receive the retransmitted 3/4. At least on Linux. While this behavior may not be explicitly allowed by the standard, it does not pose any (security) issues (AFIAK?). EAPOL frames are protected on their own. There's still a second problem: the client will retransmit 4/4 using link-layer encryption, because it already configured TX keys after transmitting the initial 4/4. As a result, the AP will not be able to receive/process the retransmitted 4/4. I'm aware that this can be solved (to a certain extend) by first configuring an RX-only key [1]. But that is still tedious and from what I can tell few implement it. *In theory*, can't all these problems be solved by always sending all EAPOL frames unencrypted? I realize this not an option in practice, since not all devices always accept unencrypted EAPOL frames (and hence it would break the rekeying case). But if we assume that everyone always accepts unencrypted EAPOL frames, then all this would be quite easy to solve by always sending unencrypted EAPOL frames as well. Does that make sense, or am I missing something? Otherwise this would be a good argument that devices should always accept unencrypted EAPOL-Key frames. Then some day in the future we can safely send EAPOL frames unencrypted, avoiding all the above issues. [1] https://mentor.ieee.org/802.11/dcn/10/11-10-0313-01-000m-rekeying-protocol-fix.ppt _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
