Couple of corrections... On 20/05/2019 17:47, Brendan Jackman wrote: > 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. I meant "right before it sends 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.. I think I have indeed misunderstood, the "default key" seems to be a device-global thing instead of per-peer (there's no MAC address in the nl80211 msg or passed to the cfg80211_ops.set_default_key). Not sure what that's for but it doesn't seem to make sense for the PTK in this context. I got to my dodgy conclusion by reading wpa_driver_nl80211_set_key and guessing what the "set_tx" param did. So, that may scupper the whole idea... > 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
