> I'm a little confused now so let me lay my scheme out really verbosely and maybe > I will answer your question... > > The correct sequence for the initial key setup is: > > 1. Complete 4-way handshake > 2. Install PTK Yes, I think so. I'd have to check the exact installation point(s) mentioned in the spec again though, not entirely sure they're really all _after_ the whole handshake. Doesn't matter in practice though. > The problem is that one of those processes takes place in the data plane and the > other in the control plane. So we don't really know that part 1 is complete > before we do part 2. So 4/4 can get encrypted with a key that the peer has not > installed. Right. > As you mentioned basically all drivers (including ours) work around this by just > specifically saying that the packets in part 1 are not encrypted even if there > is a key (I'll call this NOCRYPT). So even if part 2 interferes and the key gets > installed before 4/4 goes out, it won't get encrypted. > > So far so good. Right. > However now we get to rekeying. The ideal sequence would be: > > 1. Complete 4-way handshake, encrypting EAPoL frames with key 0, establishing key 1 > 2. Install key 1 > > Because we specify that key 0 is used to encrypt the handshake, even if > installing key 1 races against the sending of those frames, the peer can still > decapsulate them using key 0. Sure, this is fundamentally racy/broken, as long as you don't have everything in a single place/entity, which is unrealistic. > But in reality we only get to use a single key (for <5.3), so the sequence is: > > 1. Complete 4-way handshake to establish key 0' > 2. Install key 0' over the top of key 0 > > My problem boils down to the fact that if, in part 1, we encrypt the handshake > frames using key 0 (this is what the spec tells us to do), then if we hit the > installation race then 4/4 might get encrypted with 0'. I think up to this point > we are already on the same page... I think so too. > 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. 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. johannes _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
