From: Johannes Berg <johannes@sipsolutions.net>
To: Jouni Malinen <j@w1.fi>
Cc: "John W. Linville" <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org,
Jouni Malinen <jouni.malinen@atheros.com>
Subject: Re: [PATCH 12/14] mac80211: 802.11w - Optional software CCMP for management frames
Date: Wed, 07 Jan 2009 16:09:04 +0100 [thread overview]
Message-ID: <1231340944.3545.38.camel@johannes> (raw)
In-Reply-To: <20090107140956.GA22424@jm.kir.nu>
[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2009-01-07 15:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 11:23 [PATCH 00/14] mac80211: IEEE 802.11w (management frame protection) Jouni Malinen
2009-01-07 11:23 ` [PATCH 01/14] mac80211: 802.11w - STA flag for MFP Jouni Malinen
2009-01-07 11:23 ` [PATCH 02/14] mac80211: 802.11w - CCMP for management frames Jouni Malinen
2009-01-07 11:23 ` [PATCH 03/14] mac80211: 802.11w - Add BIP (AES-128-CMAC) Jouni Malinen
2009-01-07 11:23 ` [PATCH 04/14] mac80211: 802.11w - Use " Jouni Malinen
2009-01-07 11:23 ` [PATCH 05/14] mac80211: 802.11w - WEXT parameter for setting mgmt cipher Jouni Malinen
2009-01-07 11:23 ` [PATCH 06/14] mac80211: 802.11w - WEXT configuration for IGTK Jouni Malinen
2009-01-07 11:23 ` [PATCH 07/14] mac80211: 802.11w - Configuration of MFP disabled/optional/required Jouni Malinen
2009-01-07 11:23 ` [PATCH 08/14] mac80211: 802.11w - SA Query processing Jouni Malinen
2009-01-07 11:23 ` [PATCH 09/14] mac80211: 802.11w - Do not force Action frames to disable encryption Jouni Malinen
2009-01-07 11:23 ` [PATCH 10/14] mac80211: 802.11w - Drop unprotected robust management frames if MFP is used Jouni Malinen
2009-01-07 11:23 ` [PATCH 11/14] mac80211: 802.11w - Implement Association Comeback processing Jouni Malinen
2009-01-07 11:23 ` [PATCH 12/14] mac80211: 802.11w - Optional software CCMP for management frames Jouni Malinen
2009-01-07 12:08 ` Johannes Berg
2009-01-07 12:24 ` Jouni Malinen
2009-01-07 12:47 ` Johannes Berg
2009-01-07 14:09 ` Jouni Malinen
2009-01-07 15:09 ` Johannes Berg [this message]
2009-01-07 15:30 ` Jouni Malinen
2009-01-07 15:37 ` Johannes Berg
2009-01-07 16:33 ` Jouni Malinen
2009-01-07 16:37 ` Johannes Berg
2009-01-08 9:57 ` Helmut Schaa
2009-01-08 10:48 ` Jouni Malinen
2009-01-08 12:08 ` Helmut Schaa
2009-01-08 12:18 ` Jouni Malinen
2009-01-08 12:25 ` Johannes Berg
2009-01-08 12:29 ` Helmut Schaa
[not found] ` <226823.3656.qm@web57008.mail.re3.yahoo.com>
2009-01-08 12:44 ` [patch] vif_conf.patch failed to patch git wireless-testing (07-01-2009) Jouni Malinen
2009-01-07 11:23 ` [PATCH 13/14] ath9k: Fix set_key error codes Jouni Malinen
2009-01-07 11:24 ` [PATCH 14/14] ath9k: Setup MFP options for CCMP Jouni Malinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1231340944.3545.38.camel@johannes \
--to=johannes@sipsolutions.net \
--cc=j@w1.fi \
--cc=jouni.malinen@atheros.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).