If driver/firmware/hardware does not support CCMP for management
frames, it can now request mac80211 to take care of encryption and
decryption of management frames (when MFP is enabled) in software. The
driver will need to add this new IEEE80211_KEY_FLAG_SW_MGMT flag when a
CCMP key is being configured for TX side and return the encrypted frames
on RX side without RX_FLAG_DECRYPTED flag to use software CCMP for
management frames (but hardware for data frames).
Signed-off-by: Jouni Malinen <[email protected]>
---
include/net/mac80211.h | 4 ++++
net/mac80211/wpa.c | 9 +++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
--- wireless-testing.orig/include/net/mac80211.h 2009-01-07 13:07:49.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2009-01-07 13:08:07.000000000 +0200
@@ -692,12 +692,16 @@ enum ieee80211_key_len {
* generation in software.
* @IEEE80211_KEY_FLAG_PAIRWISE: Set by mac80211, this flag indicates
* that the key is pairwise rather then a shared key.
+ * @IEEE80211_KEY_FLAG_SW_MGMT: This flag should be set by the driver for a
+ * CCMP key if it requires CCMP encryption of management frames (MFP) to
+ * be done in software.
*/
enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_WMM_STA = 1<<0,
IEEE80211_KEY_FLAG_GENERATE_IV = 1<<1,
IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
IEEE80211_KEY_FLAG_PAIRWISE = 1<<3,
+ IEEE80211_KEY_FLAG_SW_MGMT = 1<<4,
};
/**
--- wireless-testing.orig/net/mac80211/wpa.c 2009-01-07 13:07:46.000000000 +0200
+++ wireless-testing/net/mac80211/wpa.c 2009-01-07 13:08:07.000000000 +0200
@@ -369,9 +369,14 @@ static int ccmp_encrypt_skb(struct ieee8
int hdrlen, len, tail;
u8 *pos, *pn;
int i;
+ bool skip_hw;
+
+ skip_hw = (tx->key->conf.flags & IEEE80211_KEY_FLAG_SW_MGMT) &&
+ ieee80211_is_mgmt(hdr->frame_control);
if ((tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) &&
- !(tx->key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV)) {
+ !(tx->key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
+ !skip_hw) {
/* hwaccel - with no need for preallocated room for CCMP
* header or MIC fields */
info->control.hw_key = &tx->key->conf;
@@ -406,7 +411,7 @@ static int ccmp_encrypt_skb(struct ieee8
ccmp_pn2hdr(pos, pn, key->conf.keyidx);
- if (key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) {
+ if ((key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) && !skip_hw) {
/* hwaccel - with preallocated room for CCMP header */
info->control.hw_key = &tx->key->conf;
return 0;
--
--
Jouni Malinen PGP id EFC895FA
On Wed, Jan 07, 2009 at 04:09:04PM +0100, Johannes Berg wrote:
> Or just adding it to nl80211, are we ever expecting to have pure wext
> drivers with MFP capabilities??
Not that likely, I would assume. However, I would rather not start
extending driver_wext.c in wpa_supplicant with nl80211 functionality and
I don't see Network Manager moving away from hardcoding driver_wext
anytime soon..
> Generally, the thing is that we don't really want to require people to
> manually enable MFP, but rather have NM set it to "enable whenever
> possible". That seems not workable unless we know which driver/hw
> supports it.
Sure. Enabling optional MFP automatically whenever driver/hw supports it
would be nice (there is a separate policy selection of requiring MFP and
that's something that users will need to configure if they want it). For
this feature, I would be fine having the optional-MFP configuration in
wpa_supplicant mean that it will be disabled if driver does not support
it, i.e., NM would not actually need to care and it could just always
set ieee80211w=1 in wpa_supplicant configuration (or well, at this
point, it would need to care a bit since wpa_supplicant would reject the
configuration if it was not built with 802.11w support, but that is
probably fine when done over dbus and not config file).
As far as wpa_supplicant is concerned, I can make it determine this by
trying to enable MFP mode at startup to figure out whether the driver is
capable, so there is no need to add an explicit capability flag for this
if we do not want to modify WEXT. For nl80211, we can add capability
flag for MFP and then driver_nl80211.c can skip this validation step.
However, we would still need to add a driver-mac80211 flag for
indicating whether the driver supports MFP.
--
Jouni Malinen PGP id EFC895FA
On Wed, Jan 07, 2009 at 04:37:51PM +0100, Johannes Berg wrote:
> > For nl80211, we can add capability
> > flag for MFP and then driver_nl80211.c can skip this validation step.
>
> Would be nice to be able to print it out in iw, just for information.
OK. I think I'll leave this as a separate step since there does not seem
to be an existing command suitable for this yet, but anyway, the
information will be available once that gets added.. This should be
something that allows the driver to be queried about general
capabilities (encr algorithms, etc., and now also MFP).
> > However, we would still need to add a driver-mac80211 flag for
> > indicating whether the driver supports MFP.
>
> Right, and once we have that the polarity of this key flag doesn't
> matter at all, though I suspect there are much fewer drivers that will
> be able to support it in hardware.
How about following on top of the MFP patch series (and a small change
to ath9k to set this flag)?
PS.
Actually, NM would probably not need to care about MFP at all (unless
user wants to require it). I think I will change wpa_supplicant default
to MFP-optional once 802.11w gets deployed and is found not to cause
problems.
---
include/net/mac80211.h | 4 ++++
net/mac80211/wext.c | 4 ++++
2 files changed, 8 insertions(+)
--- wireless-testing.orig/include/net/mac80211.h 2009-01-07 18:10:40.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2009-01-07 18:11:33.000000000 +0200
@@ -866,6 +866,9 @@ enum ieee80211_tkip_key_type {
* Hardware which has dynamic power save support, meaning
* that power save is enabled in idle periods, and don't need support
* from stack.
+ *
+ * @IEEE80211_HW_MFP_CAPABLE:
+ * Hardware supports management frame protection (MFP, IEEE 802.11w).
*/
enum ieee80211_hw_flags {
IEEE80211_HW_RX_INCLUDES_FCS = 1<<1,
@@ -879,6 +882,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SPECTRUM_MGMT = 1<<9,
IEEE80211_HW_AMPDU_AGGREGATION = 1<<10,
IEEE80211_HW_NO_STACK_DYNAMIC_PS = 1<<11,
+ IEEE80211_HW_MFP_CAPABLE = 1<<12,
};
/**
--- wireless-testing.orig/net/mac80211/wext.c 2009-01-07 18:20:30.000000000 +0200
+++ wireless-testing/net/mac80211/wext.c 2009-01-07 18:22:38.000000000 +0200
@@ -961,6 +961,10 @@ static int ieee80211_ioctl_siwauth(struc
ret = -EOPNOTSUPP;
break;
case IW_AUTH_MFP:
+ if (!(sdata->local->hw.flags & IEEE80211_HW_MFP_CAPABLE)) {
+ ret = -EOPNOTSUPP;
+ break;
+ }
if (sdata->vif.type == NL80211_IFTYPE_STATION ||
sdata->vif.type == NL80211_IFTYPE_ADHOC)
sdata->u.sta.mfp = data->value;
--
Jouni Malinen PGP id EFC895FA
On Wed, 2009-01-07 at 16:09 +0200, Jouni Malinen wrote:
> On Wed, Jan 07, 2009 at 01:47:08PM +0100, Johannes Berg wrote:
>
> > 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.
>
> Yes and that why I was considering of a flag to notify hostapd and
> wpa_supplicant about the capability.. But that would mean modifying WEXT
> even more ;-).
Or just adding it to nl80211, are we ever expecting to have pure wext
drivers with MFP capabilities??
> > 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?
>
> It is similar for both ends.. For example, wpa_supplicant does not
> enable MFP on the client side by default, i.e., both hostapd and
> wpa_supplicant behave the same in the sense that MFP needs to be
> explicitly enabled.
>
> > 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?
>
> MFP is negotiated in RSN IE and in case of mac80211, it would need to be
> going to userspace since wpa_supplicant builds the RSN IE (and well,
> hostapd obviously does the same for Authenticator side). We could a new
> WEXT capability (e.g., IW_ENC_CAPA_MFP) for this, if desired.. It would
> also be possible already with the current patchset to probe for this by
> setting IW_AUTH_MFP and see whether the driver returns EOPNOTSUPP, so in
> that sense, wpa_supplicant (and hostapd) could already figure this out
> before trying to associate.
Generally, the thing is that we don't really want to require people to
manually enable MFP, but rather have NM set it to "enable whenever
possible". That seems not workable unless we know which driver/hw
supports it.
johannes
Am Donnerstag, 8. Januar 2009 schrieb Jouni Malinen:
> However, at this point I would not yet
> recommend trying to use driver_nl80211 as the first option. Once we get
> nl80211 bit more complete and at least make sure it does not break
> something, adding the automatic driver selection would sound more
> reasonable.
Right. Sounds feasible.
> Though, this would also mean that we depend on drivers never
> implementing partial nl80211 support that could trigger wpa_supplicant
> into believing that they support nl80211 when they would actually work
> much better with wext.
Good point.
Helmut
Am Donnerstag, 8. Januar 2009 schrieb Jouni Malinen:
> On Thu, Jan 08, 2009 at 10:57:45AM +0100, Helmut Schaa wrote:
>
> > Jouni, what do you think about extending wpa_supplicant to allow mutliple
> > drivers to be set on the commandline (-Dnl80211,wext). The supplicant would
> > then try to register the first driver and only if that fails it takes the next
> > one (e.g. try nl80211 first and if that fails use wext). That way NM could
> > use nl80211 for drivers that support nl80211 (mainly mac80211-drivers) and
> > wext for the other drivers by passing "-Dnl80211,wext" to the supplicant.
>
> Well, that could be done inside wpa_supplicant, but more or less the
> same effect should already be doable by NM trying to first add the
> interface with nl80211 as the driver interface and if that fails, fall
> back to wext.
True. However, other consumers of wpa_supplicant (e.g. Yast in SUSE) could
also benefit from this feature if implemented inside the supplicant. But as
I wrote, this was just a quick thought on how to make the transition from
wext to nl80211 smoother.
Helmut
On Wed, 2009-01-07 at 18:33 +0200, Jouni Malinen wrote:
> How about following on top of the MFP patch series (and a small change
> to ath9k to set this flag)?
Looks good to me.
> PS.
>
> Actually, NM would probably not need to care about MFP at all (unless
> user wants to require it). I think I will change wpa_supplicant default
> to MFP-optional once 802.11w gets deployed and is found not to cause
> problems.
True. Except that there probably will be problems unless everybody
implements it perfectly...
> ---
> include/net/mac80211.h | 4 ++++
> net/mac80211/wext.c | 4 ++++
> 2 files changed, 8 insertions(+)
>
> --- wireless-testing.orig/include/net/mac80211.h 2009-01-07 18:10:40.000000000 +0200
> +++ wireless-testing/include/net/mac80211.h 2009-01-07 18:11:33.000000000 +0200
> @@ -866,6 +866,9 @@ enum ieee80211_tkip_key_type {
> * Hardware which has dynamic power save support, meaning
> * that power save is enabled in idle periods, and don't need support
> * from stack.
> + *
> + * @IEEE80211_HW_MFP_CAPABLE:
> + * Hardware supports management frame protection (MFP, IEEE 802.11w).
> */
> enum ieee80211_hw_flags {
> IEEE80211_HW_RX_INCLUDES_FCS = 1<<1,
> @@ -879,6 +882,7 @@ enum ieee80211_hw_flags {
> IEEE80211_HW_SPECTRUM_MGMT = 1<<9,
> IEEE80211_HW_AMPDU_AGGREGATION = 1<<10,
> IEEE80211_HW_NO_STACK_DYNAMIC_PS = 1<<11,
> + IEEE80211_HW_MFP_CAPABLE = 1<<12,
> };
>
> /**
> --- wireless-testing.orig/net/mac80211/wext.c 2009-01-07 18:20:30.000000000 +0200
> +++ wireless-testing/net/mac80211/wext.c 2009-01-07 18:22:38.000000000 +0200
> @@ -961,6 +961,10 @@ static int ieee80211_ioctl_siwauth(struc
> ret = -EOPNOTSUPP;
> break;
> case IW_AUTH_MFP:
> + if (!(sdata->local->hw.flags & IEEE80211_HW_MFP_CAPABLE)) {
> + ret = -EOPNOTSUPP;
> + break;
> + }
> if (sdata->vif.type == NL80211_IFTYPE_STATION ||
> sdata->vif.type == NL80211_IFTYPE_ADHOC)
> sdata->u.sta.mfp = data->value;
>
>
On Wed, 2009-01-07 at 13:23 +0200, Jouni Malinen wrote:
> plain text document attachment (ieee80211w-sw-mgmt-ccmp.patch)
> If driver/firmware/hardware does not support CCMP for management
> frames, it can now request mac80211 to take care of encryption and
> decryption of management frames (when MFP is enabled) in software. The
> driver will need to add this new IEEE80211_KEY_FLAG_SW_MGMT flag when a
> CCMP key is being configured for TX side and return the encrypted frames
> on RX side without RX_FLAG_DECRYPTED flag to use software CCMP for
> management frames (but hardware for data frames).
Wouldn't it be better to invert the meaning of the flag so we don't have
to update all drivers now? It's likely that people won't test CCMP hw
encryption and also that it won't work, I'd think, no?
johannes
On Thu, Jan 08, 2009 at 10:57:45AM +0100, Helmut Schaa wrote:
> Jouni, what do you think about extending wpa_supplicant to allow mutliple
> drivers to be set on the commandline (-Dnl80211,wext). The supplicant would
> then try to register the first driver and only if that fails it takes the next
> one (e.g. try nl80211 first and if that fails use wext). That way NM could
> use nl80211 for drivers that support nl80211 (mainly mac80211-drivers) and
> wext for the other drivers by passing "-Dnl80211,wext" to the supplicant.
Well, that could be done inside wpa_supplicant, but more or less the
same effect should already be doable by NM trying to first add the
interface with nl80211 as the driver interface and if that fails, fall
back to wext.
--
Jouni Malinen PGP id EFC895FA
On Wed, Jan 07, 2009 at 01:08:38PM +0100, Johannes Berg wrote:
> On Wed, 2009-01-07 at 13:23 +0200, Jouni Malinen wrote:
> > plain text document attachment (ieee80211w-sw-mgmt-ccmp.patch)
> > If driver/firmware/hardware does not support CCMP for management
> > frames, it can now request mac80211 to take care of encryption and
> > decryption of management frames (when MFP is enabled) in software. The
> > driver will need to add this new IEEE80211_KEY_FLAG_SW_MGMT flag when a
> > CCMP key is being configured for TX side and return the encrypted frames
> > on RX side without RX_FLAG_DECRYPTED flag to use software CCMP for
> > management frames (but hardware for data frames).
>
> Wouldn't it be better to invert the meaning of the flag so we don't have
> to update all drivers now? It's likely that people won't test CCMP hw
> encryption and also that it won't work, I'd think, no?
I did consider this, but could not convince myself that drivers would be
expected to work without some testing and likely changes.. 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.
--
Jouni Malinen PGP id EFC895FA
On Thu, Jan 08, 2009 at 01:08:21PM +0100, Helmut Schaa wrote:
> True. However, other consumers of wpa_supplicant (e.g. Yast in SUSE) could
> also benefit from this feature if implemented inside the supplicant. But as
> I wrote, this was just a quick thought on how to make the transition from
> wext to nl80211 smoother.
Agreed and it should be relatively small change in wpa_supplicant, so
I'm not against doing this. However, at this point I would not yet
recommend trying to use driver_nl80211 as the first option. Once we get
nl80211 bit more complete and at least make sure it does not break
something, adding the automatic driver selection would sound more
reasonable. Though, this would also mean that we depend on drivers never
implementing partial nl80211 support that could trigger wpa_supplicant
into believing that they support nl80211 when they would actually work
much better with wext.
--
Jouni Malinen PGP id EFC895FA
On Wed, Jan 07, 2009 at 01:47:08PM +0100, Johannes Berg wrote:
> 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.
Yes and that why I was considering of a flag to notify hostapd and
wpa_supplicant about the capability.. But that would mean modifying WEXT
even more ;-).
> 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...
If that is the case, it would be just a quick test and one-liner to the
driver to fix it. As long as the hardware/firmware does not touch
received management frames that have Protected field set to one it
should be fine (some try to use same rules as for data frames and that
will fail).
> 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?
It is similar for both ends.. For example, wpa_supplicant does not
enable MFP on the client side by default, i.e., both hostapd and
wpa_supplicant behave the same in the sense that MFP needs to be
explicitly enabled.
> 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?
MFP is negotiated in RSN IE and in case of mac80211, it would need to be
going to userspace since wpa_supplicant builds the RSN IE (and well,
hostapd obviously does the same for Authenticator side). We could a new
WEXT capability (e.g., IW_ENC_CAPA_MFP) for this, if desired.. It would
also be possible already with the current patchset to probe for this by
setting IW_AUTH_MFP and see whether the driver returns EOPNOTSUPP, so in
that sense, wpa_supplicant (and hostapd) could already figure this out
before trying to associate.
--
Jouni Malinen PGP id EFC895FA
On Thu, 2009-01-08 at 14:18 +0200, Jouni Malinen wrote:
> Agreed and it should be relatively small change in wpa_supplicant, so
> I'm not against doing this. However, at this point I would not yet
> recommend trying to use driver_nl80211 as the first option. Once we get
> nl80211 bit more complete and at least make sure it does not break
> something, adding the automatic driver selection would sound more
> reasonable. Though, this would also mean that we depend on drivers never
> implementing partial nl80211 support that could trigger wpa_supplicant
> into believing that they support nl80211 when they would actually work
> much better with wext.
That's not _much_ of a problem, considering that driver_nl80211 is using
wext, and cfg80211 will continue providing wext calls. Therefore, older
versions of wpa_supplicant will continue working on newer kernel
versions that have more stuff in nl80211 rather than wext, the only
problem could come up when using a "too new" wpa_supplicant on an older
kernel with older nl80211. That's easy to detect though by checking
which commands nl80211 supports, and refusing to work with it unless all
commands that driver_nl80211 needs are implemented.
johannes
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
Am Mittwoch, 7. Januar 2009 schrieb Jouni Malinen:
> On Wed, Jan 07, 2009 at 04:09:04PM +0100, Johannes Berg wrote:
>
> > Or just adding it to nl80211, are we ever expecting to have pure wext
> > drivers with MFP capabilities??
>
> Not that likely, I would assume. However, I would rather not start
> extending driver_wext.c in wpa_supplicant with nl80211 functionality and
> I don't see Network Manager moving away from hardcoding driver_wext
> anytime soon..
I guess NetworkManager won't move away from wext unless all drivers
support nl80211.
Jouni, what do you think about extending wpa_supplicant to allow mutliple
drivers to be set on the commandline (-Dnl80211,wext). The supplicant would
then try to register the first driver and only if that fails it takes the next
one (e.g. try nl80211 first and if that fails use wext). That way NM could
use nl80211 for drivers that support nl80211 (mainly mac80211-drivers) and
wext for the other drivers by passing "-Dnl80211,wext" to the supplicant.
That's just a quick thought but I'd like to hear your opinion.
Helmut
On Wed, 2009-01-07 at 17:30 +0200, Jouni Malinen wrote:
> Sure. Enabling optional MFP automatically whenever driver/hw supports it
> would be nice (there is a separate policy selection of requiring MFP and
> that's something that users will need to configure if they want it).
Indeed
> For
> this feature, I would be fine having the optional-MFP configuration in
> wpa_supplicant mean that it will be disabled if driver does not support
> it, i.e., NM would not actually need to care and it could just always
> set ieee80211w=1 in wpa_supplicant configuration (or well, at this
> point, it would need to care a bit since wpa_supplicant would reject the
> configuration if it was not built with 802.11w support, but that is
> probably fine when done over dbus and not config file).
Right.
> As far as wpa_supplicant is concerned, I can make it determine this by
> trying to enable MFP mode at startup to figure out whether the driver is
> capable, so there is no need to add an explicit capability flag for this
> if we do not want to modify WEXT.
Makes sense, yeah.
> For nl80211, we can add capability
> flag for MFP and then driver_nl80211.c can skip this validation step.
Would be nice to be able to print it out in iw, just for information.
> However, we would still need to add a driver-mac80211 flag for
> indicating whether the driver supports MFP.
Right, and once we have that the polarity of this key flag doesn't
matter at all, though I suspect there are much fewer drivers that will
be able to support it in hardware.
johannes