[PATCH] rsn_supp: Don't encrypt EAPOL-Key 4/4.

[Jouni Malinen]

On Mon, Feb 13, 2012 at 08:20:53AM +0100, Andreas Hartmann wrote:
> The dropping of the frames starts directly after 2/4 has been done and
> 3/4 has been sent the first time (long before the first 4/4 timeout). I
> could see, that the first few frames (mostly data frames I suppose) are
> dropped here:
> 
>         if (!(status->flag & RX_FLAG_DECRYPTED)) {
>                 /* hardware didn't decrypt/verify MIC */
>                 if (ieee80211_aes_ccm_decrypt(
>                         return RX_DROP_UNUSABLE;

Huh.. The key should not have changed yet on either the AP or the
station..

> One of the dropped frame is the 4/4 frame from wpa_supplicant.

Just to make sure.. This happened even for the case where only a single
3/4 had been transmitted and the first attempt at sending 4/4 was
dropped?

> If the legacy ralink driver internal supplicant is used, the connection
> isn't interrupted, because ralink sends 4/4 unencrypted (the behavior of
> the data frames is the same as wrote above, but this is no problem,
> as they are just resent after a few millisecs and the connection
> doesn't break down).

The AP behaves incorrectly, if it accepts unencrypted EAPOL frame during
PTK rekeying. Sure, with that kind of AP behavior, it would be trivial
to avoid the issue by not encrypting the frame, but this is not the way
RSN is supposed to work.

> As it is sent unencrypted (the same way as during initial rekeying), I
> hope that the sent data is already internally encrypted (or it is just
> useless for any attacker, even if he get them unencrypted), so it
> shouldn't be a problem, if the frame itself isn't encrypted.

There are no know security attacks even if the frame were sent
unencrypted. However, the RX rules on the other device (AP in this case)
should force the frame to be dropped because a TK was configured for the
transmitting STA and the frame was not protected.

> Why isn't it just possible to send one of thousands of frames
> unencrypted? Just tag it with "unencrypted", so the driver knows, that
> this frame musn't be encrypted at all - independently if there is a
> key for encryption present or not.

It is not that much of a problem of being able to do this, but the
problem of this not being the correct way of handling this.. If that AP
was indeed using mac80211, too, I think we need to fix the AP behavior
to drop such a frame.

I would like to better understand which key is used for each frame
during PTK rekeying. I'd guess that wireless capture file here can get
pretty huge, so it may be easier if I try to reproduce that myself.

If you are interested in running it through an analysis, I would suggest
using wlantest (in the wlantest directory of hostap.git). If you provide
it the needed keys (e.g., passphrase for WPA2-Personal), it will go
through a wireless capture file and decrypt all the frames and decrypt
the keys from both the initial 4-way handshake and PTK rekeys. It will
complain about incorrectly protected frames, so it would be interesting
to see what it says about the rekeying 4-way handshake.

-- 
Jouni Malinen                                            PGP id EFC895FA