On Mon, May 18, 2015 at 6:02 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2015-05-18 at 06:14 +0000, Peer, Ilan wrote: > >> There is probably no synchronization between the 4way HS and other >> data traffic on the transmitter side, as these are different >> processes. So it is possible that after receiving message 3 and before >> setting the keys, the HW would be able to decrypt additional frames >> with the old key. > > Right. I think the "new key with old PN" part is probably not really > happening, although it seems possible. I'd think we should look at the > receiver first and only then move on to the transmitter if issues > persist. Having a sniffer capture of the problem with known keys (!) > would be useful though. > The submitter seems to say he sees the new key with old PN in the air. He attached sniffer captures with known keys. I guess that Wireshark is able to try different keys and check which one is the one that leads to a successful decryption. https://bugzilla.kernel.org/show_bug.cgi?id=92451#c14 I can indeed see that the PN is going back to one way after the EAPOL frame exchange is finished. Note that Windows doesn't seem to be suffering from this problem (again - based on what the user said). So basically, the sender is not behaving nice. It bumps the PN of the new key. If the sender would have kept using the old key for a while and change the IV and the key atomically, we would have been fine. We would have dropped the packets until the sender finally uses the new key, and this would not have bumped the PN of the new key. The problem (IMHO) is that the sender use the *new* key which means that there is no decryption failure with the old PN. And only later the PN goes back to 1. I don't know how we can possibly work around this. And just like the user is saying, I wonder how Windows doesn't suffer from the same problem as mac80211... > >> AFAIK, the PTK is installed immediately after the 4th message is sent >> without waiting to ACK or any other delay. As the AP (should) installs >> the keys only after processing the 4th message, so a delay is >> expected. > > Makes sense. > > johannes > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
