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

[Nicolas Cavallari]

On 08/02/2012 12:31, Andreas Hartmann wrote:
> Nicolas Cavallari schrieb:
>> 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.
> 
> Please, may I ask you a question?
> 
> I do encounter here a similar (?) problem since ages. hostapd sends 3/4
> to supplicant, supplicant sends 4/4 and is ready and all is fine.
> 
> But there is one problem: it only works, as long as there is no data
> stream (payload) active between supplicant and hostapd.
> If there is payload at the same time (e.g. created with netperf), 4/4 is
> sent by supplicant (can be seen in wireshark), but isn't seen by
> hostapd. hostapd therefore retries 3/4, but supplicant doesn't see these
> packages any more: connection is broken, because hostapd closes the
> connection because of missing 4/4!

Which driver(s) do you use ?

It could be the same problem or a different one. Do you have a trace
made from a separate interface in monitor mode ? that way we could see
which packets are encrypted or not, and which are acked... logs from the
both side might be useful too.

But the fact that the supplicant cannot receive the duplicated 3/4 frame
might indicate something. You are seeing this at key renegotiation time,
right ?