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

Jouni Malinen j
Sun Feb 12 12:47:17 PST 2012

On Sun, Feb 12, 2012 at 09:27:25PM +0100, Nicolas Cavallari wrote:
> Then ... what do you expect "setprotection(rx)" to actually do,
> if not instead of not crypting in the tx path ? Considering that the
> standard does not require supporting more than one PTK per station, and
> that the linux kernel does not support it either...

Well, this is not really described in the MLME primitives, or well, not
really in the standard in general, but the only way to implement this
correctly seems to require support for two PTKs that can be in use for
the small amount of time during rekeying. I'm not aware of any
implementation doing this either.

> Anyway, it won't solve Andreas' problem : the 4/4 frame is queued behind
> a handful of data frames, control is resumed to wpa_supplicant, which
> sets the key just after. When the kernel flush his queue, it already
> uses the new key, so sends 4/4 encrypted with the new PTK ...   Solving
> this might require something more than just "setprotection".

What were those other data frames? If this is during the initial 4-way
handshake, the port (PAE) should be unauthorized and other data frames
apart from EAPOL frames should be blocked. Sure, we may not yet support
PAE in station mode, but in theory, that's the way it is supposed to
work. As far as rekeying is concerned, this gets quite a bit more
complex (until the newly defined non-zero key index PTK gets into use).

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list