Dealing with retransmitted EAPOL msg 3/4 and 4/4

[Mathy Vanhoef]

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