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

[Andreas Hartmann]

Jouni Malinen schrieb:
> 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?

Yes.

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

It is hostap-d3f57d0, hostap-1rc behaves exactly the same. Driver is
nl80211, 80211.n (g behaves exactly the same). I can see it with ath9k
and rt2800pci (didn't test any more) on AP side. Same problem can be
seen with Linksys WAP610N as AP.

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

If it works the protected way - but what is with supplicants sending
unencrypted frames (I believe windows does the same, as I didn't have
this problem with windows stations, too).

>> 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 think this would be a bad idea, because it would break compatibility
(see above) and it would be against the defined standard (according
Nicolas).

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

That's right - the files get really huge :-(.

> 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

I'm using eap-tls, but psk shows exactly the same problem.

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

I'll try my best. But it should be really easy for you to reproduce this
problem yourself, as it comes up here in 99%.


Kind regards,
Andreas