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

[Nicolas Cavallari]

On 12/02/2012 20:43, Jouni Malinen wrote:
> On Sun, Feb 12, 2012 at 07:35:40PM +0100, Nicolas Cavallari wrote:
>> On 12/02/2012 19:25, Jouni Malinen wrote:
>>> It would not make difference for the initial 4-way handshake at the
>>> beginning of the association, but it breaks PTK rekeying, i.e., another
>>> 4-way handshake during the association. In that exchange, all EAPOL
>>> frames need to be encrypted with the old key.
>> Where is that specified ? My interpretation of the standard is that
>> setprotection(rx) is called before sending 4/4, so Tx encryption
>> should be disabled for 4/4 ...
> In the IEEE 802.11 standard obviously.. ,-)  Though, it may be a bit
> difficult to find this and some reading between lines may also be
> needed.
I would be interested to know more about those between-lines-readings
... because i still don't understand how rsn is supposed to not break.
>> If you don't want to not encrypt 4/4, there is no need to implement
>> setprotection(rx)...
> There is. The key point here is that the 4-way handshake (including
> retries) is expected to be completed with the PTK that was in use at the
> beginning of the handshake. In other words, all four EAPOL messages in
> the 4-way handshake at the beginning of the association are unprotected
> while all four EAPOL messages (including retries) in the PTK rekeying
> 4-way handshakes are encrypted using the old PTK.
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...

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