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:
signature.asc
Description: This is a digitally signed message part
