Re: set key and separate default keys

[Jouni Malinen <j@w1.fi>]

On Sun, May 01, 2011 at 11:29:46AM +0200, Johannes Berg wrote:
> On Sat, 2011-04-30 at 19:30 -0700, Naveen Singh wrote:
> > The WPA-PSK association was not going through with 2.6.38
> > kernel. It was found that supplicant was not able to set
> > the PTK key. On further analysis it was found that the function
> > nl80211_set_key in file net/wireless/nl80211.c is returning with
> > code as -EOPNOTSUPP. This function has been modified to check for
> > the flag "WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS"in wiphy
> > struct. If this flag is not set in the driver init, it returns
> > from here thereby causing the association to fail. The solution
> > is to set this flag in driver init as there would be separate
> > default keys for unicast and multicast packets.

> We were discussing this before ... and I think the bug is in the
> supplicant actually asking for the GTK to be set as the default key or
> something like that.

Well, I'm not sure I would call it a bug, but more like a no-op
currently as far as PTK is concerned (that's the one that was failing in
this particular case). I don't remember whether the earlier discussion
was on PTK or GTK, but if it was for GTK, that would be more or less
pointless operation for RX-only key. In addition, the requirements
depend of which operation mode is used (STA/IBSS/AP) and change with
things like multiple PTK support in the future.

> In any case, this doesn't seem right unless you actually do support
> separate unicast keys. Are you sure you fully understand what you're
> doing here, and not just randomly hacking in a workaround?

Going through this was actually an interesting process.. A single flag
may not actually cover all the cases since some of these are quite
obviously separate default keys (e.g., AP mode and GTK) and for the
driver to be able to get that working, it looks like it has to set this
flag. However, that may not be the same situation in station mode.

As an immediate fix for the regression, I think it would be useful to
apply this patch in the driver. It is correct at least for AP mode and
somewhat irrelevant for station mode. I did not verify IBSS case yet.

For a more complete solution, we may want to consider splitting this
capability flag per mode or some other way of avoiding parts of the
extra validation that causes a regression with the deployed
wpa_supplicant versions.

-- 
Jouni Malinen                                            PGP id EFC895FA