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

Jouni Malinen j at
Wed Mar 8 03:59:52 PST 2017

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

More information about the Hostap mailing list