On 27/08/2019 19:11, Johannes Berg wrote: >> So, what if we just don't encrypt the rekeying handshake frames either >> (i.e. keep th NOCRYPT workaround going)? The problem is that the peer should >> reject them according to the spec. So let's say we just have the peer allow >> unencrypted frames during an RSNA as long as they are EAPoL. This is easier said >> than done (at least in my case - perhaps I am a special case here?) because the >> MAC layer whose job is to discard unencrypted frames has no business peering at >> the ethertype or whatever. Similarly for the part where we discard GCMP replays >> (unencrypted frames don't have a packet number at all!). > > In mac80211, we specifically allow unencrypted EAPOL frames to be > received, because also some WPA1 APs allow them, and WAPI requires this > (IIRC), and for various other reasons. We have to look at the ethertype > anyway at some point, so not sure I agree with that part of your > statement. When I say "has no business peering" I'm not just talking about a philosophical distaste for it - I actually mean in our current architecure the components that discard frames for RSNA reasons don't have physical access (or it would be costly to performance) to the ethernet header. So we'd basically need to change those components so that where currently they cause the frame to be discarded, they instead cause it to be passed on up and just set a flag somewhere to say "discard that frame if it doesn't turn out to be EAPoL". Or, more accurately "discard all the MSDUs in that MPDU that don't turn out to be EAPoL". I must admit: perhaps we'll need to do this in the end anyway for interop reasons. And perhaps this is a totally unique issue for our architecture which doesn't really justify changing generic code. But anyway perhaps you can see why I've been hesitant to do it. > In general though, yes, I think you're right. We just allow them > unencrypted for interoperability, but I'm not sure we actually transmit > them unencrypted. > >> So in our driver we use the NOCRYPT workaround for the initial handshake, but >> then _don't_ use it for the rekeying handshake (i.e. we _do_ encrypt EAPoL >> frames during rekeying). But that means we are vulnerable to the race condition >> and indeed we see rekeying fail if there is heavy traffic on the link. >> >> So the idea is that by moving part 1. into the control plane to some degree >> (i.e. into nl80211) we can fully complete establishment of key 0', using >> handshake frames encrypted with key 0, before we install key 0' (by flushing the >> TX ring in part 2). So now the NOCRYPT workaround is not necessary to avoid lost >> handshake packets, neither for the initial nor for rekeying handshakes. > > Right, OK. I forgot (again) you were worried about the rekeying mostly. > > Nevertheless, I think this means that we do need to have the NO_ENCRYPT > flag set to keep the *initial* handshake working, no? Or actually fix > the race conditions you pointed out above for it. While for the > rekeying, well, it basically cannot work and you just move it to the > control plane to have more control over it, which also makes sense. .tx_control_port + a TX ring flush in .add_key should fix both the initial and rekeying handshake without any need for NO_ENCRYPT. The handshake frames will always go out before the key (re)installation takes place, which means: - The handshake frames for the initial key setup will all go out unencrypted (because the MAC has no keys). - The handshake frames for rekeying will all go out encrypted with the old key, before the new key gets installed. (If there is data flowing, some will probably be lost at this point, but the EAPoL frames will be fine which is the most important thing). I should also say that with Alexander Wetzels' work on Extended Key ID support going on as it is, my patch here would only end up really mattering for users of kernels between v4.19 and v5.3 (I think). So yeah, if you do not think my justifications are strong enough, I would understand. Cheers, Brendan _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
