Question on IBSS + RSN

[Jouni Malinen]

On Wed, Jan 11, 2017 at 05:56:01PM -0800, Ben Greear wrote:
> Hello!

Looks like there are still some issues in getting your messages through
to the list..

> I am trying again to get IBSS + RSN working with ath10k.  After tweaking the
> firmware a bit, it sometimes works, but often it does not.  In particular,
> it appears that one side will be able to send and receive (and decode properly),
> and the other side can send properly, but the other side cannot decode.
> 
> Perhaps in a simpler case, I sometimes see one side send EAPOL 1/4, and the peer responds
> with what is almost certainly an encrypted EAPOL 2/4.
> 
> At other times, both sides do the EAPOL 4-way at the same time, and then I see
> all 4 messages for each peer in wireshark (each of them are not encryped).
> 
> For now, I would like to try to debug and understand this EAPOL issue.
> 
> First, which part of the code determines if EAPOL messages should be
> encrypted or not?

Ignoring WPA (the original version, i.e., not WPA2) and IEEE 802.1X
(dynamic WEP), the actual WPA2/RSN cases are pretty clear: EAPOL frames
are encrypted if TK is configured and enabled for TX and are sent in
plain if TK is not configured (or enabled for TX). In practice, the
initial EAP authentication (if any) and the first 4-way handshake are
sent in clear and everything after that is sent encrypted.

> Is it ever valid for an EAPOL 2/4 to be encrypted?

Yes, that would be the case when using 4-way handshake to rekey the
pairwise key.

As far as the specific RSN IBSS case is concerned, it sounds like either
the existing key is not cleared when it should be (on receiving
Authentication frame) or a request to clear the key is not send (a STA
can send out an Authentication frame to clear the peer TK to recover
from cases where the other end has a key and the local end had to be
restarted in a manner that lost its TK). 
 
-- 
Jouni Malinen                                            PGP id EFC895FA