On Sat, May 16, 2015 at 09:57:09PM +0200, Johannes Berg wrote: > The key index is used for GTK rekeying. The spec makes no provision for > seamless PTK rekeying, it's simply not supported. > > There was/is work in progress to actually change that, but I haven't > seen anything definitive. Jouni might know more. It was added in IEEE Std 802.11-2012. Search for Extended Key ID for Individually Addressed Frames subfield of the RSN Capabilities field (a field within RSN element). I'm not sure whether anyone has implemented this, but anyway, we could relatively easily add support for this with mac80211 + hostapd + wpa_supplicant combination. Though, probably that would end up depending on a new driver capability flag, so only with some drivers. > As I said, I believe at this point the only way to fix this bug is to > try to drop *old* key packets immediately, but it's difficult to ensure > this. Effectively, it would require synchronising RX vs. key > installation. I did not look at the details of the reported issue. Was this an issue in a received frame with old key being processed by mac80211 after key change and while doing that, ending up configuring incorrect (way too large) RX PN for the new key? Dropping the frames with the old key would be one option, but not really ideal. A somewhat nicer option would be to add a concept of generation to the key (i.e., the 1st, 2nd, ... key using key index N) and with the help of drivers (that can do this), indicate which generation of the key was used for RX decryption. This would allow proper replay protection for both keys if we were to store copies of the RX counters for both the previous and current key in mac80211. -- Jouni Malinen PGP id EFC895FA -- 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
