No broadcast after 2nd rekey using extended key IDs

[James Prestwood]

Soon after clicking send I believe I figured this out. I had been
rekeying by sending REKEY_GTK then immediately sending REKEY_PTK.

This actually caused a GTK only rekey, then a PTK + GTK rekey. I still
think there is some race in hostapd since it apparently did not install
the second GTK key, hence I lost broadcast.

Its unlikely but I still think this this could cause problems. For
example:

A station leaves causing a GTK rekey. Then a station rekey timer
happens to fire immediately after causing a rekey for that station (PTK
+ GTK). This may cause the same behavior I am seeing, but hard to know
for sure.

On Fri, 2021-10-01 at 13:17 -0700, James Prestwood wrote:
> Hi,
> 
> While implementing extended key IDs for IWD I ran into this problem
> where a second set of rekeys (PTK + GTK) ended up losing broadcast
> traffic. Figuring it was a bug in my code I tried the same setup with
> wpa_supplicant + hostapd and ran into the exact same behavior.
> 
> Monitoring NL80211 I can see there isn't much difference between my
> implementation and wpa_supplicant, in short both do the following:
> 
>  - Parse the extended key ID KDE from message 3
>  - Use NEW_KEY with an RX only flag
>  - Send message 4
>  - Use SET_KEY with TX enable flag
> 
> The kernel is happy with this, and the first rekey does in fact work.
> But when I rekey again I lose broadcast. One thing to note is that if
> I
> only rekey the PTK I can do this many times (I tried 10 in a row).
> 
> One thing I noticed is that the PTK key ID toggles between 0 and 1,
> and
> the GTK key ID toggles between 1 and 2. They are never the same value
> at the same time, of course. I'm thinking the kernel has the old PTK
> and is using that instead of the GTK since the indexes (1) overlap.
> 
> I can send logs upon request, but large messages need approval and in
> the past I haven't had much luck with that.
> 
> Thanks,
> James
>