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