On Thu, 2015-12-31 at 10:41 +0200, Emmanuel Grumbach wrote:

It simply disables the replay attack detection :)
You could receive the same (encrypted) packet twice and not throw
away the second one.

Correct.

PTK rekeying is a problem from the spec point of view. 

Which was/is being addressed too, with different key index being
allowed now. We just haven't implemented it yet, and in the case at
hand the AP also won't be requesting it and the enhancement wouldn't be
used anyway.

In Intel, we
did inquiries and in the end we understood that what we should really
do whenever we get to a situation where we need to rekey the PTK is
to disconnect and reconnect. Only weird configuration allow to change
the PTK more frequently than after X packet (don't remember what X is
but something like 2^32 which is big enough to hold the connection
for days...).

wpa_supplicant could easily disconnect.

IIRC, Intel devices don't have problems in Tx while we rekey because
we give the key material along with the packet itself, so that we
can't get to a situation where we have old PN and new key.

Yeah, that's my recollection as well. Emmanuel, remember though we're
going to change this, which could become problematic. We might want to
implement the disconnection once we change it, and also implement the
new spec way of PTK rekeying (with key index).

 The Atheros
devices separate the key material and the Tx packet (which is a
perfectly valid design decision), but this introduce the possibility
to use the old PN with a new key meaning that the recipient could
decrypt the packet after the new key has been installed, but it would
also update the PN to be high and discard all the next packets that
will come with a new (low) PN.
So essentially, this is a bug in the TX'ing side. Fixing it requires
to hit the performance which is not something people are willing to
do, when the bug is really in the spec.
That's what I remember, but I may be wrong.

It matches what I remember too :)

johannes