This is the first and still quite preliminary version of changes to
introduce IEEE 802.11w (management frame protection) support into
mac80211. As such, I'm mainly looking for comments on the current
design to help me in finalizing and cleaning up the patches.
Please note that couple of small additions to hostapd and wpa_supplicant
are required to actually configure MFP and those are not yet included in
the hostap git repository. Consequently, this is not yet available for
real testing. Or well, if you really want to test this now, I can send
an experimental patch to hostapd/wpa_supplicant to enable MFP support.
The current version is relatively complete for mac80211, but there are
still couple of known missing functions and I've done only very
limited testing so far. I was able to send and receive both CCMP and
BIP protected deauthentication frames and based on a sniffer log, the
frames looked correct. All this is with mac80211_hwsim and software
crypto. It is unclear whether this can be used as-is with devices that
use hwaccel for crypto at least before the low-level drivers and/or
firmware have been modified to cope with the possibility of CCMP being
used with management frames.
This patch set does not address the issues found in configuring default
keys for monitor interfaces, i.e., this still needs a workaround in
hostapd to set IGTK for both wlan# and mon.wlan#. In addition, the
debugfs directory is left behind when the monitor interface is removed.
Since IEEE 802.11w draft is still in progress and open to changes, it is
also unclear whether we would actually like to introduce IEEE 802.11w
support as-is into mac80211 in main line kernels at this point. Then
again, IEEE 802.11w draft is quite a bit further in the standardization
process than IEEE 802.11s draft and we already have some pre-standard
mesh support in mac80211 at least in wireless-testing.
--
Jouni Malinen PGP id EFC895FA
On Tue, 2008-06-17 at 19:52 +0200, Michael Buesch wrote:
> On Tuesday 17 June 2008 19:47:49 Jouni Malinen wrote:
> > On Tue, Jun 17, 2008 at 06:44:27PM +0200, Johannes Berg wrote:
> >
> > > > crypto. It is unclear whether this can be used as-is with devices that
> > > > use hwaccel for crypto at least before the low-level drivers and/or
> > > > firmware have been modified to cope with the possibility of CCMP being
> > > > used with management frames.
> > >
> > > b43 will be able to do this for sure, it doesn't care what sort of frame
> > > is encrypted. The question is how drivers can indicate
> > > support/non-support I guess.
> >
> > One of the problems is that CCMP as defined in IEEE 802.11i for data
> > frames is not compatible with CCMP as defined in IEEE 802.11w for
> > management frames (there are small differences in AAD and nonce
> > generation). As such, if the hardware/firmware is trying to decrypt
> > received CCMP protected frames based on the IEEE 802.11i rules even if
> > the frame is a management frame, the end result is not going to be very
> > good..
Oh, ok, never mind then. Probably not worth accelerating anyway.
> Well, as long as the checksum will fail in that case we're OK for b43,
> as the driver will notify the need for software crypto for those packets.
I don't think it'll try to decrypt them anyway but I thought we could
at least use it to encrypt.
johannes
On Tue, Jun 17, 2008 at 06:44:27PM +0200, Johannes Berg wrote:
> > crypto. It is unclear whether this can be used as-is with devices that
> > use hwaccel for crypto at least before the low-level drivers and/or
> > firmware have been modified to cope with the possibility of CCMP being
> > used with management frames.
>
> b43 will be able to do this for sure, it doesn't care what sort of frame
> is encrypted. The question is how drivers can indicate
> support/non-support I guess.
One of the problems is that CCMP as defined in IEEE 802.11i for data
frames is not compatible with CCMP as defined in IEEE 802.11w for
management frames (there are small differences in AAD and nonce
generation). As such, if the hardware/firmware is trying to decrypt
received CCMP protected frames based on the IEEE 802.11i rules even if
the frame is a management frame, the end result is not going to be very
good.. It would be necessary to either disable hwaccel for CCMP
decryption for management frames (if possible) or add software
workaround to re-encrypt the management frame incorrectly (to undo
hardware/firmware operations) and then decrypt it in software..
--
Jouni Malinen PGP id EFC895FA
> The current version is relatively complete for mac80211, but there are
> still couple of known missing functions and I've done only very
> limited testing so far. I was able to send and receive both CCMP and
> BIP protected deauthentication frames and based on a sniffer log, the
> frames looked correct. All this is with mac80211_hwsim and software
> crypto. It is unclear whether this can be used as-is with devices that
> use hwaccel for crypto at least before the low-level drivers and/or
> firmware have been modified to cope with the possibility of CCMP being
> used with management frames.
b43 will be able to do this for sure, it doesn't care what sort of frame
is encrypted. The question is how drivers can indicate
support/non-support I guess.
johannes
On Tue, 2008-06-17 at 20:27 +0200, Michael Buesch wrote:
> On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
> > On Tue, Jun 17, 2008 at 07:52:52PM +0200, Michael Buesch wrote:
> >
> > > Well, as long as the checksum will fail in that case we're OK for b43,
> > > as the driver will notify the need for software crypto for those packets.
> >
> > Yes, MIC won't match (or well, in theory it could, but in practice..)
> > and if the original frame is available after failed hw-decryption
> > attempt, this is indeed all that's needed here. Some hardware designs
> > are not able to deliver the unmodified frame due to the way AES hwaccel
> > is implemented in them and that gets bit tricky to handle in software
> > for IEEE 802.11w.
>
> Yeah I see. Probably need to disable HW crypto for them.
> (If firmware modification to pass MGMT frames untouched is impossible)
Broadcom's firmware already passes MGMT frames through untouched (unless
they are auth frames and those aren't protected in 802.11w I think.)
johannes
On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
> On Tue, Jun 17, 2008 at 07:52:52PM +0200, Michael Buesch wrote:
>
> > Well, as long as the checksum will fail in that case we're OK for b43,
> > as the driver will notify the need for software crypto for those packets.
>
> Yes, MIC won't match (or well, in theory it could, but in practice..)
> and if the original frame is available after failed hw-decryption
> attempt, this is indeed all that's needed here. Some hardware designs
> are not able to deliver the unmodified frame due to the way AES hwaccel
> is implemented in them and that gets bit tricky to handle in software
> for IEEE 802.11w.
Yeah I see. Probably need to disable HW crypto for them.
(If firmware modification to pass MGMT frames untouched is impossible)
--
Greetings Michael.
On Tue, Jun 17, 2008 at 06:40:08PM +0300, Jouni Malinen wrote:
> This is the first and still quite preliminary version of changes to
> introduce IEEE 802.11w (management frame protection) support into
> mac80211. As such, I'm mainly looking for comments on the current
> design to help me in finalizing and cleaning up the patches.
Thanks for the comments! I think I resolved most of them and made my
current set of patches available at http://w1.fi/mfp/ in order to avoid
having to post them to the list after all minor changes. I'll send new
versions to the list once I get some more known issues resolved and the
patches are closer to being ready to be included in wireless-testing.
--
Jouni Malinen PGP id EFC895FA
On Tuesday 17 June 2008 19:47:49 Jouni Malinen wrote:
> On Tue, Jun 17, 2008 at 06:44:27PM +0200, Johannes Berg wrote:
>
> > > crypto. It is unclear whether this can be used as-is with devices that
> > > use hwaccel for crypto at least before the low-level drivers and/or
> > > firmware have been modified to cope with the possibility of CCMP being
> > > used with management frames.
> >
> > b43 will be able to do this for sure, it doesn't care what sort of frame
> > is encrypted. The question is how drivers can indicate
> > support/non-support I guess.
>
> One of the problems is that CCMP as defined in IEEE 802.11i for data
> frames is not compatible with CCMP as defined in IEEE 802.11w for
> management frames (there are small differences in AAD and nonce
> generation). As such, if the hardware/firmware is trying to decrypt
> received CCMP protected frames based on the IEEE 802.11i rules even if
> the frame is a management frame, the end result is not going to be very
> good..
Well, as long as the checksum will fail in that case we're OK for b43,
as the driver will notify the need for software crypto for those packets.
--
Greetings Michael.
On Tue, Jun 17, 2008 at 07:52:52PM +0200, Michael Buesch wrote:
> Well, as long as the checksum will fail in that case we're OK for b43,
> as the driver will notify the need for software crypto for those packets.
Yes, MIC won't match (or well, in theory it could, but in practice..)
and if the original frame is available after failed hw-decryption
attempt, this is indeed all that's needed here. Some hardware designs
are not able to deliver the unmodified frame due to the way AES hwaccel
is implemented in them and that gets bit tricky to handle in software
for IEEE 802.11w.
--
Jouni Malinen PGP id EFC895FA
On Tuesday 17 June 2008 20:31:47 Johannes Berg wrote:
> On Tue, 2008-06-17 at 20:27 +0200, Michael Buesch wrote:
> > On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
> > > On Tue, Jun 17, 2008 at 07:52:52PM +0200, Michael Buesch wrote:
> > >
> > > > Well, as long as the checksum will fail in that case we're OK for b43,
> > > > as the driver will notify the need for software crypto for those packets.
> > >
> > > Yes, MIC won't match (or well, in theory it could, but in practice..)
> > > and if the original frame is available after failed hw-decryption
> > > attempt, this is indeed all that's needed here. Some hardware designs
> > > are not able to deliver the unmodified frame due to the way AES hwaccel
> > > is implemented in them and that gets bit tricky to handle in software
> > > for IEEE 802.11w.
> >
> > Yeah I see. Probably need to disable HW crypto for them.
> > (If firmware modification to pass MGMT frames untouched is impossible)
>
> Broadcom's firmware already passes MGMT frames through untouched (unless
> they are auth frames and those aren't protected in 802.11w I think.)
Ah I see. Makes sense.
--
Greetings Michael.
On Wed, Jul 09, 2008 at 08:08:56PM +0200, Johannes Berg wrote:
> Just realised that it doesn't handle VLANs properly. Could you add a
> static MAC/VLAN mapping to hostapd to make VLANs possible without
> setting up radius? :)
Well, I could, but this doesn't sound like a real world feature.. I
would assume it would be relatively simple addition to the file-based
MAC ACL (accept_mac_file) to allow optional listing of VLAN ID that
would then be used as if it came from the authentication server.
Anyway, It shouldn't require much complexity to set up FreeRADIUS with
two users that are assigned to different VLAN groups. hostapd.conf lists
the needed tunnel attributes for this.. ;-)
--
Jouni Malinen PGP id EFC895FA
On Wed, 2008-07-09 at 19:40 +0200, Johannes Berg wrote:
> > This patch set does not address the issues found in configuring default
> > keys for monitor interfaces, i.e., this still needs a workaround in
> > hostapd to set IGTK for both wlan# and mon.wlan#. In addition, the
> > debugfs directory is left behind when the monitor interface is removed.
>
> Can you try this patch?
> http://johannes.sipsolutions.net/patches/kernel/all/2008-07-09-17%3a38/021-mac80211-inject-sdata.patch
>
> It should use the sdata from the TA instead of the monitor when treating
> injecting frames, where possible.
Just realised that it doesn't handle VLANs properly. Could you add a
static MAC/VLAN mapping to hostapd to make VLANs possible without
setting up radius? :)
johannes
> This patch set does not address the issues found in configuring default
> keys for monitor interfaces, i.e., this still needs a workaround in
> hostapd to set IGTK for both wlan# and mon.wlan#. In addition, the
> debugfs directory is left behind when the monitor interface is removed.
Can you try this patch?
http://johannes.sipsolutions.net/patches/kernel/all/2008-07-09-17%3a38/021-mac80211-inject-sdata.patch
It should use the sdata from the TA instead of the monitor when treating
injecting frames, where possible.
johannes
On Thu, 2008-08-28 at 19:04 +0300, Jouni Malinen wrote:
> On Wed, Jul 09, 2008 at 08:08:56PM +0200, Johannes Berg wrote:
>
> > Just realised that it doesn't handle VLANs properly. Could you add a
> > static MAC/VLAN mapping to hostapd to make VLANs possible without
> > setting up radius? :)
>
> In order to get more people testing this, I finally gave in and added
> that option into hostapd ;-), so now you can do this without having to
> set up a RADIUS server. To make things even easier, I made an example
> configuration and test instructions for mac80211_hwsim available:
>
> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=mac80211_hwsim/tests/0002-vlan
Awesome, thanks. I'll look at the code, it seems to me that I actually
want to be able to configure to not reject unknown stations but put them
into their own VLAN, or something, then this feature could actually be
useful in production.
> I started collecting mac80211_hwsim test cases into mac80211_hwsim/tests
> directory in hostap.git. I hope this will make it easy for developers to
> test mac80211 features. For the time being, this is for manual testing,
> but hopefully at some point these tests can be run automatically with a
> script (e.g., daily or whenever wireless-testing changes, etc.). The
> test.txt file includes the commands needed to run both the AP and
> client(s). Some additional infrastructure would be needed to validate
> the end results and start/stop wpa_supplicant and hostapd in the
> background.
I'm not so much worried about starting/stopping them, you can easily
write a small program or so that simply forks and then runs them in the
foreground so that it has control over them and knows what PIDs they
have etc.
The validation is a bit harder, you can listen for wext events, but you
can't even try pinging between the interfaces... Maybe the validation
should check what's going on on the "air".
johannes
On Friday 29 August 2008 10:37:41 Jouni Malinen wrote:
>
> debugfs provides some help for things like VLAN (or well, would provide,
> if we actually showed that information there ;-), but that can be easily
> added). As far as data packets are concerned, we could implement a
> simple "ping" program that uses packet sockets to send some data (and
> reply to specific messages). This can then by-pass the issues with IP
> and local interface.
>
Hello all, I saw the test driver project in kernelnewbies.org, posted by
Johannes, so I was working a little bit on the subject.
I am an absolute newbie, but I would like to share my thoughts while I was
working on this and seeing mac80211_hwsim. Again, probably most of them are
useless, but give me a try :). This is gonna be a little bit off-topic...
sorry.
First of all, I built a fool bus, just for plugging and unplugging the devices
on it (using debugfs for this task). I think it was the better way for
simulate a real device structure, but in fact is totally useless :$.
> It would be useful to have a tool that processes hwsim0 dump, though,
> and provides a language for writing "expect scripts" for 802.11
> (+radiotap) frames.. For example, something like "EXPECT ProbeReq CHAN=1
> SRC=<mac> DST=<bcast>; EXPECT ProbeResp CHAN=1 SRC=<bssid> DST=<mac>"
> and so on.. That tool would then write a report on what happened and
> provided pass/fail result based on requirements in the script.
Then, every device has debugfs I/O files (well, writing isn't working properly
yet). I tought it was the best way to allow an user tool to handle
configurations and communication with devices. I mean, the 'air' would be these
debugfs files next to an user tool to simulate what you want using them.
Well, the next two weeks are my exams period, so i will be out of service, but
I would like to help with this. Therefore, I'll pay attention to the list just
in case I could help with this stuff.
Regards,
Jose Ignacio.
On Wed, Jul 09, 2008 at 08:08:56PM +0200, Johannes Berg wrote:
> Just realised that it doesn't handle VLANs properly. Could you add a
> static MAC/VLAN mapping to hostapd to make VLANs possible without
> setting up radius? :)
In order to get more people testing this, I finally gave in and added
that option into hostapd ;-), so now you can do this without having to
set up a RADIUS server. To make things even easier, I made an example
configuration and test instructions for mac80211_hwsim available:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=mac80211_hwsim/tests/0002-vlan
I started collecting mac80211_hwsim test cases into mac80211_hwsim/tests
directory in hostap.git. I hope this will make it easy for developers to
test mac80211 features. For the time being, this is for manual testing,
but hopefully at some point these tests can be run automatically with a
script (e.g., daily or whenever wireless-testing changes, etc.). The
test.txt file includes the commands needed to run both the AP and
client(s). Some additional infrastructure would be needed to validate
the end results and start/stop wpa_supplicant and hostapd in the
background.
--
Jouni Malinen PGP id EFC895FA
On Fri, Aug 29, 2008 at 09:33:31AM +0200, Johannes Berg wrote:
> Awesome, thanks. I'll look at the code, it seems to me that I actually
> want to be able to configure to not reject unknown stations but put them
> into their own VLAN, or something, then this feature could actually be
> useful in production.
That would require a bit more code to have the default VLAN ID for
unknown STAs stored somewhere, but that should be relatively small
change to hostapd with all the other VLAN ID processing available.
> The validation is a bit harder, you can listen for wext events, but you
> can't even try pinging between the interfaces... Maybe the validation
> should check what's going on on the "air".
debugfs provides some help for things like VLAN (or well, would provide,
if we actually showed that information there ;-), but that can be easily
added). As far as data packets are concerned, we could implement a
simple "ping" program that uses packet sockets to send some data (and
reply to specific messages). This can then by-pass the issues with IP
and local interface.
It would be useful to have a tool that processes hwsim0 dump, though,
and provides a language for writing "expect scripts" for 802.11
(+radiotap) frames.. For example, something like "EXPECT ProbeReq CHAN=1
SRC=<mac> DST=<bcast>; EXPECT ProbeResp CHAN=1 SRC=<bssid> DST=<mac>"
and so on.. That tool would then write a report on what happened and
provided pass/fail result based on requirements in the script.
--
Jouni Malinen PGP id EFC895FA