Re: [PATCH 12/14] mac80211: 802.11w - Optional software CCMP for management frames

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

On Wed, 2009-01-07 at 14:24 +0200, Jouni Malinen wrote:

> I did consider this, but could not convince myself that drivers would be
> expected to work without some testing and likely changes.. 

Ok, I guess in that case it doesn't really matter much, though it'd be
good to not randomly associate to an AP that has MFP enabled when we
don't know the hardware can handle it.
I know, for example, that Broadcom hardware can handle it just fine when
done in software, but I'm pretty sure it cannot handle it in hardware
crypto...

> I do not care
> that much which way this is, so if you want this to be inverted, that's
> fine, too. I might even go as far as adding an explicit capability flag
> that drivers will need to set to claim MFP support and export this to
> userspace so that hostapd/wpa_supplicant could refuse the configuration
> early. With that kind of flag, inverting this key flag does not get much
> since the drivers would need to be changed anyway for MFP to work in
> every case.

You seem to be concerned only about AP mode, while I'm not much
concerned about that, there it's always tested explicitly by the person
setting up the AP, but someone who's just using STA mode would now
suddenly potentially run into problems when using an AP that is
MFP-enabled, no?

Hence, I think adding an explicit flag (whether it needs to be exported
to userspace I don't know) would probably be good so if the driver/hw
really cannot handle MFP at all then we don't associate using it, no?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]