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

[Jouni Malinen]

On Mon, Feb 06, 2012 at 06:39:02PM +0100, Nicolas Cavallari wrote:
> When the 4/4 pairwise handshake is lost, the authenticator
> will retry 3/4 and we would resent 4/4, but encrypted.
> 
> 802.11 spec implies that EAPOL 4/4 should not be encrypted, but
> because setprotection is not implemented by any (non-testing) driver,
> clear the key before sending EAPOL-Key 4/4 and reset the key
> just after.


> This is just a proposed solution to a problem that i'm having.  I don't
> think it is the best nor it does not break something else, so i'm asking
> what would be the right approach here.  I was also thinking about
> reusing hostapd's eapol_send.

Well, the proper approach would be to implement setprotection rather
than this workaround..

> I'm currently experimenting with a IBSS RSN network of 4 station, but
> while testing, there are always two or more handshakes that fails,
> because of a lost EAPOL-Key 4/4 frame.  In IBSS mode, the two station
> will not retry association, so the network will not recover and will
> eventually split.
> 
> Also, between the time where 3/4 was received by the supplicant and 4/4
> was received by the authenticator, the opposite four way handshake is
> stalled for the same reason.

These are bit problematic to fix in any other way than by adding support
for unidirectional (RX only) key operations, i.e., MLME-SETPROTECTION
primitives. The AP (or well, Authenticator to include IBSS case) side
may start transmitting encrypted frames immediately after receiving
EAPOL-Key 4/4 and trying to remove/add keys on the STA/Supplicant side
is opening a race condition here.

-- 
Jouni Malinen                                            PGP id EFC895FA