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

[Nicolas Cavallari]

On 06/02/2012 21:05, Jouni Malinen wrote:
> On Mon, Feb 06, 2012 at 06:39:02PM +0100, Nicolas Cavallari wrote:
>> 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..

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

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

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.