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

[Jouni Malinen]

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.

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

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

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.

-- 
Jouni Malinen                                            PGP id EFC895FA