Hi Denis, > Hi Alexander, > >>>> hostapd or wpa_supplicant are "ordering" mac80211 to install a new key >>>> and are implementing the state machine and are in a good position to >>>> handle the fallout... at least theoretically. >>> >>> Ideally it would even know beforehand that we don't want to handle the >>> PTK rekeying, and then could reconnect instead of going through the >>> handshake. >>> >> >> Don't see how we could do that in the kernel, all the relevant >> information is handled in the state machine. I guess an API extension >> telling hostap/supplicant if we can handle rekeys or not would tbe he >> only way to avoid that. >> > > Can the kernel / driver provide some sort of hint to user space that PTK > rekey isn’t supported? We could then have user space deauthenticate > with a big warning about what/why this is happening and try to > re-connect to the last used BSS. > Sure. In fact the latest patch is already doing that by returning an error when set_key is called for PTK and it's not an initial call. Tests with wpa_supplicant shows that this is is then handled like the initial key set is failing. Networkmanager prompts for the password and wpa_supplicant running without seems to blacklist a reconnect for 15s. I kind of liked that solution, but with existing implematations out this is indeed awkward to find a "correct" solution. The main problem for me currently is to find a correct and still acceptable solution. This turned from "let's fix this nasty wlan connection freezes" to a projet spanning the complete wlan stack: From hardware up to and including the userspace... It's fun to learn how that interacts (if not very fast), I'm stuggling finding the best way forward here. Whatever we do has undesired consequences. Maybe I'm missing something, but here the high level options we have in my opinion: 1) Keep it as it is and solve that in a indefinite future when we and the world implement the ieee802.11 2012 addition, to use key 0+1 for PTK and 2+3 for GTK - rekey has a extrem high probability of freezing connections and leaking a few clear text packets for years (decades?) to come + The issue is fixed at the core 2) Make it worse, like some (most) Windows systems/cards seem to handle it by encrypting EAPOL #4 with the NEW key, breaking the handshake and forcing a reconnect. - break something more to fix a problem sounds like a insane approach + This seems to be quite common and therefore well "tested" (based on my very limited data on that) 3) Fix what we can in mac80211 but keep the API stable - Without driver actions still many drivers will be "undefined" and even if they are not freezing leak packets + This will reduce the problems to a fraction of what is is today with only a mac80211 update 4) Redesign the mac80211 rekey handling and interaction with drivers to only rekey if it is save and decline when not. + We only have to touch the kernel - any supplicant (whatever runs the wpa state machine) may get errors where the programmes did not expect them, leading to unexpected side effects. 5) The full-stack solution: Update the API for the userpace + We do not have to "trick" the wpa state machine to disconnect, the programmers of it have to code it. - Well, it must be suppurted from the wpa state machine. If not we still have to handle the rekey somehow or we accept freezes/cleartext leaks... The last two solutions will also need some "fallback" when a secure rekey is not possible and/or the user is runing an old state machine not knowing about the new way... >>> So I think we're probably better off accepting the set_key but not >>> actually using it, and instead disconnecting... even if that's awkward >>> and should come with a big comment :-) >> >> Instead of returning an error I'll change the code to accept the rekey >> but do nothing with it. (Basically delete the new key and keep the old >> active). >> And of course calling ieee80211_set_disassoc() prior to return "success". >> >> Let's see how the supplicant will react on a disassoc while doing a >> rekey... >> > > This sounds pretty awful actually. Now that wpa_s is not the only game > in town, can we stop resorting to these tactics? Nothing of it is wpa_supplicat/hostap specifiy. Only my current "test" environment is using it, simply due to the fact that I tracked the issue down in that environment. Everything besides ath9k as an AP running hostapd and a iwldvm card running wpa_supplicant is mostly untested. And even there I have some areas marked for follow up after we find a solution acceptable for the kernel... Do you have any other software you think I should add to my prelimitary tests? If possible I'll happy to extend the test of the patches with those. Alexander
Attachment:
pEpkey.asc
Description: application/pgp-keys
