Hi all, I'm working on software for a DMG implementation (802.11ad/ay) using RSN, GCMP, 802.1X auth, and for a while we've been working around this issue: the MLME protocol/NL80211 doesn't provide any ordering between key setup and data transmission. During PTK rekeying, on receipt of message 3/4 the supplicant derives the new key, sends 4/4, then installs the new key and installs it to the MAC. However there's no guarantee that 4/4 is actually sent before the new key is installed, so it can get encrypted with the new key, which the authenticator has not yet installed. We see this issue for real on our systems when message 4/4 shares a stream with other in-flight data. I believe this is a well-known issue - is that correct? Sometimes we've partially worked around this issue by just not encrypting EAPOL frames. However to turn this into a completely reliable solution places quite a burden on the RX path: MPDU decapsulation status needs to be tracked right up until the moment we can tell whether an MSDU was EAPOL or not, and it even has an impact on receive buffer processing (MPDU reordering under block ack) requirements. So I've been looking for a way to sort it out in the higher layers. It seems to me that the proper solution is described in 802.11-2016 12.7.6.4.4 - "4-way handshake message 3". If both peers report Extended Key ID for Individually Addressed Frames (WPA_CAPABILITY_EXT_KEY_ID_FOR_UNICAST) in their RSN capabilities, then we alternate between key IDs 0 and 1 for each rekeying handshake. The authenticator installs the new key for RX as soon as it hears 3/4. That means if the supplicant ends up encrypting 4/4 with the new key, no problem - the authenticator can still decapsulate it. Then once it's got 4/4 it sets up the new key for TX too (and should delete the old one, I guess). I originally intended this mail to include a hacky patch to implement this, but it turns out Linux rejects pairwise GCMP keys with nonzero index - the comment[1] says: /* Disallow pairwise keys with non-zero index unless it's WEP * or a vendor specific cipher (because current deployments use * pairwise WEP keys with non-zero indices and for vendor * specific ciphers this should be validated in the driver or * hardware level - but 802.11i clearly specifies to use zero) */ [1] https://elixir.bootlin.com/linux/v5.1.3/source/net/wireless/util.c#L240 I don't understand that rationale or where in 802.11 we are told to use zero - could anyone clarify? Supposing I was able to change Linux to allow nonzero key indexes, would the mechanism I've described be viable or does hostap have its own reasons for insisting on zero key indexes? If we implement this in hostap, what is the best way to get the information on whether the kernel driver supports multiple live keys; add a new NL80211 extended feature? If we know the driver supports it then IIUC hostapd and wpa_supplicant can assert WPA_CAPABILITY_EXT_KEY_ID_FOR_UNICAST in the nl IE attrs that go alongside NL80211_CMD_START_AP and NL80211_CMD_CONNECT respectively. Also, when I talked earlier about installing keys "for RX" and "for TX", I am assuming that, if the driver supports it, you can do a NL80211_CMD_NEW_KEY to install the key without yet starting to encapsulate with it - then subsequently NL80211_CMD_SET_KEY(NL80211_ATTR_KEY_DEFAULT) to start actually using it for TX. Let me know if I've misunderstood there.. Thanks for reading! Brendan PS, another solution I considered is just finding a way to provide an ordering guarantee between key installation and the data stream - it sort of looks as though NL80211_CMD_CONTROL_PORT_FRAME is designed to do this sort of thing, but I think to solve this problem you'd need the kernel driver's cfg80211_ops.tx_control_port to block until the frame has actually been sent. mac80211 (only provider in the mainline kernel kernel of tx_control_port) doesn't seem to do that. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
