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

[Nicolas Cavallari]

On 12/02/2012 15:39, Jouni Malinen wrote:
> On Tue, Feb 07, 2012 at 12:52:54PM +0100, Nicolas Cavallari wrote:
>> If i implement setprotection, there are still drivers that won't or
>> can't support it... that mean different code path depending on if the
>> driver support it or not, because if the driver does not support it but
>> we assume it does, we would set a key for rx and tx ... before sending
>> 4/4.  I already fell into that trap ;)
>> I'll start experimenting a setprotection implementation anyway...
> Well, how many of drivers support RSN IBSS in the first place? For
> infrastructure BSS, re-association seems like a reasonable workaround
> for recovering from this.
carl9170, ath9k, ath5k, ath9k_htc, and all mac80211-based drivers with
pure software crypto...
>
>> This race condition already exists; the supplicant currently set the key
>> after sending 4/4, this patch does not change anything about that. The
>> same race also exist in the authenticator case, after receiving 4/4, and
>> we can't do much to protect against that one. Both are
>> equally feasible in IBSS mode, because the opposite four way hs is
>> occurring at the same time.
> Fair enough. Though, this patch does break PTK rekeying since it clears
> the PTK in the middle of 4-way handshake that was supposed to be
> completed using encrypted EAPOL frames.
It clears a key just before sending 4/4, and the new PTK will be set
just after sending 4/4.
So clearing the key or not will make no difference, apart from
respecting the standard when we do (and when it works), because the
standard actually use setprotection(rx) instead. It will likely not
change the various races that exists when sending frames while changing
keys that Andreas is likely experiencing.

> IBSS cases can be somewhat complex. I haven't really went through all
> the details for them, but in general, setprotection mechanism is
> something that I've wanted to see for a long time (i.e., way before RSN
> IBSS supported was added).
In terms of PTK, IBSS isn't much different from the PTK releying case:
there is just traffic going on during the negociation. The opposite four
way handshake is just here to exchange a GTK.
As for my current setprotection() call, it will likely only implement
the Tx part (choosing between Rx only and Rx_Tx), and won't necessarily
solve race conditions, so i'm not that much motivated to try it.
>
> Even if you were to be able to work around some initial connection
> cases by forcing EAPOL frames to be unencrypted, rekeying is likely to
> have similar race conditions.
Yes : If a 4/4 is lost during rekeying, the retransmitted 3/4 cannot be
interpreted by the supplicant anymore. The standard somewhat "authorize"
stations to store more than one PTK for a TA/RA pair, but does not
define how to use them...