>> 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?
>
> hostapd does not (yet) support extended Key ID and all code has been writen with the assumptions that PTK keys must use KeyID 0.
> Using a linux kernel, hostpad and a driver supporting Extended Key ID will of
> course work. Question is, if you can get that working properly with your card
> and it's a valid solution for your scenario.
>
>>
>> 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.
>
> Linux 5.2 signals support for drivers supporting Extended Key ID with NL80211_EXT_FEATURE_EXT_KEY_ID
>
>
>> 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..
>
> Extended Key ID needs a way to tell the driver to not use a PTK key immediately for Tx. linux 5.2 adds the key flags NL80211_KEY_NO_TX and NL80211_KEY_SET_TX for that.
>
>
>>
>> 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.
>
> That also would solve the problem, at least as long as your card generates the
> PN in HW. But my stand here is, that a driver which encrypts a packet with the
> wrong key is broken and should be fixed.
Yep, in my case the PNs and all 802.11 headers are generated in HW. As I said
above I don't really understand how it's possible for a driver not to have this
bug with current info - I may still be missing something or maybe the situation
is different for mac80211 drivers, which I am not really familiar with. Our
driver gets a stream of MSDUs (inc. EAPoL) and a stream of cfg80211 calls, with
no ordering between the two. Aside from teaching the driver to understand EAPoL
and deduce where in the MSDU stream it is supposed to switch keys, I don't see a
way out.
Using mac80211 or not is not changing anything here. And indeed, the
description how it's for your card maps pretty good to mac80211 also.
So you are right: Without using tx_control_port there is a chance that
the key install may reach the card prior to EAPOL#4, regardless if you
are using mac80211 or not.
I assume the buffer bloat cleanups makes it hard or if we are lucky even
impossible to trigger that issue nowadays. I'm not familiar with that
part of the network stack, yet. At least I've not noticed issues with
EAPOL#4 with my cards so far. But then neither of them are DMGs..
Since writing my original mail and looking at the patches you linked above, I
realised that I do not actually need my .tx_control_port to block until the
frame is sent; instead I can just flush the TX queue before overwriting
PTK0. IIUC this is an incomplete solution with current userspace, because 4/4
may not have reached the HW ring before the flush happens. However if 4/4 is
sent using tx_control_port then the driver is empowered to know that it is
already in the ring when it gets the key installation, so a flush is guaranteed
to solve the problem. (Like in mac80211 - ieee80211_hw_key_replace says that
ieee80211_flush_queues "*may* help prevent the clear text leaks and freezes.";
if I'm not mistaken then if tx_control_port is in use and doesn't do any
intermediate queueing, it will *certainly* prevent the freezes). Realising that
I can solve the issue without having my cfg80211 hooks behave so differently
from mac80211 made me less dismissive of EAPoL-over-NL80211 as a solution.
Agree:-)
But when you have freezes:
I would not expect (long) freezes when you send out EAPOL#4 encrypted
with the wrong key: If memory serves me right hostapd should disconnect
you after some seconds (10s max), forcing a reconnect. Now that could
well translate to around 30s without working transmissions, but nothing
I would call a freeze.
Re-associating seems to be a acceptable alternative to rekeying the
connection, as long as this happens fast. I'm planning to teach
wpa_supplicant and iwd to do that for drivers not supporting PTK0 rekey
but probably not in the near future. (My patch so far is far too slow to
reconnect to be acceptable.)
The final solution I'm aiming for is Extended Key ID for the "optimal"
rekeys, PTK0 rekey when the driver signals he can handle it and
disconnect/reconnect for the rest.
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
