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

[Jouni Malinen]

On Wed, Mar 08, 2017 at 03:08:07AM +0100, Mathy Vanhoef wrote:
> 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.

The client is not behaving correctly in such a case. EAPOL-Key msg 4/4
should be sent without encryption if msg 3/4 is retried for this
instance of the 4-way handshake. Or if this 4-way handshake is for
rekeying after a key has previously been set, this retry should use the
old key.

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

That is needed for WPA, but with WPA2 (= RSN), unencrypted EAPOL frames
are not supposed to be accepted after TK has been configured. Not
encrypting the 4-way handshake used for rekeying the PTK is unlikely to
be noticeably less secure than the initial 4-way handshake at the
beginning of the association.

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

That has certainly implementation complexities, but that is the way the
protocol has been defined to work.

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

If one were to ignore what the standard says and don't care about
interoperability with compliant implementation, sure, one could
implement this differently. I don't think this is an acceptable way of
addressing this in practice, though, even if the standard were to be
modified (which I would not support either) since things will need to
continue to work with deployed devices that do not get updates for the
modified standard.

-- 
Jouni Malinen                                            PGP id EFC895FA