On Tue, 2018-07-10 at 14:16 -0500, Denis Kenzior wrote: > > I'm not sure I see much point, since we'll have to deal with older wpa_s > > basically forever? > > Do we though? I can understand not breaking userspace APIs, but it > seems like this API had only a single user (up until recently) and it > 'should' be acceptable to break ancient versions of it. Whether we can > or not is a question for the wider community though... I don't think so. It'll be hurting various consumers like Android, Chrome, etc. "Ancient" versions is also relative - there hasn't been a release of wpa_s in a long time, for example. > > > Put another way, should we deprecate the whole > > > NL80211_KEY_DEFAULT_TYPE_UNICAST attribute? > > > > Perhaps. I'm not sure I see much point in it. The WEP case above is > > pretty fringe, and wext didn't support it, so ... probably not needed? > > Should we at least take this out of the driver API then and have it > ignored by nl80211? And maybe mark this deprecated in the docs? I guess we could do that, yeah. > > > And since you went off on a tangent (maybe this needs a separate > > > discussion?) but... Can you elaborate about PTK rekeying with a non-zero > > > key index? Are you saying that in IBSS/AP mode we can't support PTK rekey? > > > > We can't properly support PTK rekeying in any mode, see Alexander > > Wetzel's patch and the whole discussion on the different versions I had > > with him. I'll merge his patch soon I think, but it doesn't really work > > properly. > > I think we had this conversation before. Up to 802.11-2012, PTK Rekey > was not really explicitly mentioned as possible. There were hints and > stuff, but no explicit language. Actually it was sort of forbidden - key index had to be 0 for PTK, and so you couldn't do a proper hand-over. > I think in 802.11-2016 they finally explicitly say that this is possible. Yes. > However, we seem to have networks that perform PTK Rekey and even full > 802.1X re-auth every hour (eduroam for example). How is this working? > Or is it a case of it not always working? It's not working well in practice, see Alexander's patchset. > > Some time relatively recently (802.11-2016 I think) the spec has > > introduced a method to indicate that you support what was previously not > > allowed at all: using non-zero key index for a PTK. This way, you can do > > transparent PTK rekeying like you do with GTK now, by switching to a new > > key index when you rekey. > > And keep the old one for whatever packets are in process, right? That > makes more sense. Like GTK - you just keep it "forever" (until the next rekey round) for RX, but nobody uses it for TX anymore. > > We don't - currently - support this in mac80211 or even wpa_supplicant, > > and I expect many devices would have issues with this with hardware > > offload. I'm also not aware of any certification program for it, but I > > also haven't followed the WPA3 efforts (but I don't think they're > > focused here, they're focused on algorithms and higher layers IIRC.) > > Does the recent PMK handshake offload support proposal take into > consideration PTK rekeying? No, I don't think the two are related? If you offload the handshake, you may or may not implement PTK rekeying in the 802.11-2016 or in the non- working way ... > > > > (The difference between them is that in IBSS you will have per-station > > > > GTKs, but that's also irrelevant because those are only used for RX - > > > > your own GTK on the netdev/wdev/sdata/vif level is used for TX.) > > > > > > Okay, so for GTKs we would have a per-station RX GTK and a 'default' TX > > > GTK. So in this case a SET_KEY would be needed only on the 'default' TX > > > GTK index. > > > > > > Okay, maybe a tangent, but this brings up a question: Why do we have > > > separate steps for this operation? Can't we just issue a NEW_KEY and > > > have the kernel figure this out? > > > > I think the only case would be WEP? > > So can we expect all drivers to operate this way? Or should we maybe > also have nl80211 call set_key operation on a key with no associated STA > implicitly? I don't know what drivers do, but I guess you could find out pretty easily and then do that, yeah. I suspect they just all ignore it because they couldn't figure out what the point was :) > > > So I'd like to bring up a point I mentioned in the original message, > > > should ieee80211_set_default_key() be made to return an error if > > > userspace is trying to mess with a non-existent key? That is > > > effectively what happens in the STA log provided... > > > > Perhaps, though that might break wpa_s? > > > > Doesn't wpa_s ignore most errors anyway? :) Many, but you never really know without trying :) johannes
