2009-05-11 18:58:49

by Jouni Malinen

[permalink] [raw]
Subject: [PATCH 0/4] nl80211/mac80211: Fix station mode key setup issues

When using nl80211, we cannot currently set drop_unencrypted flag that
was used with WEXT to avoid need for IEEE 802.1X port control in station
mode. Because of this, we cannot currently set the keys in a secure way.
In addition, we do not support setting the expected RSC for keys either
with WEXT or nl80211 which is needed to avoid leaving a window for
replaying broadcast frames.

This set of patches addresses these issues and allows nl80211 to
securely set up keys in station mode. This is on top of the pending
MFP patches, RX-drop-unencrypted-based-on-key-setup, and WEXT key
handling to cfg80211 patches (from Johannes).

--
Jouni Malinen PGP id EFC895FA


2009-05-11 19:27:03

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH 0/4] nl80211/mac80211: Fix station mode key setup issues

On Mon, 2009-05-11 at 21:57 +0300, Jouni Malinen wrote:
> When using nl80211, we cannot currently set drop_unencrypted flag that
> was used with WEXT to avoid need for IEEE 802.1X port control in station
> mode. Because of this, we cannot currently set the keys in a secure way.
> In addition, we do not support setting the expected RSC for keys either
> with WEXT or nl80211 which is needed to avoid leaving a window for
> replaying broadcast frames.
>
> This set of patches addresses these issues and allows nl80211 to
> securely set up keys in station mode. This is on top of the pending
> MFP patches, RX-drop-unencrypted-based-on-key-setup, and WEXT key
> handling to cfg80211 patches (from Johannes).

Looks good to me, thanks. One thing I'm not sure about though, is there
no need to push the RSC to hardware for some hw crypto designs? But even
if needed that can always be a separate patch.

johannes


Attachments:
signature.asc (801.00 B)
This is a digitally signed message part

2009-05-11 19:38:44

by Jouni Malinen

[permalink] [raw]
Subject: Re: [PATCH 0/4] nl80211/mac80211: Fix station mode key setup issues

On Mon, May 11, 2009 at 09:26:58PM +0200, Johannes Berg wrote:

> Looks good to me, thanks. One thing I'm not sure about though, is there
> no need to push the RSC to hardware for some hw crypto designs? But even
> if needed that can always be a separate patch.

There probably would be for drivers that take care of replay protection
(which should be identifiable by searching for RX_FLAG_IV_STRIPPED). It
looks like we have couple of such drivers. However, I'm not familiar
with any of those, so someone more familiar with the driver code and
hardware/firmware design should take a look.

As an example, drivers/net/wireless/wl12xx/acx.h seems to define a
set_key structure (struct acx_set_key) that includes fields for RSC.
However, the values seem to be defined based on TKIP, so I don't know
how they would be used for CCMP (and not even the byte order that would
be used for TKIP). In other words, this type of cases will require
proper testing to make sure that we do not break frame reception
completely.

Anyway, it sounds reasonable to add rsc into struct ieee80211_key_conf
to provide this information for the driver. That should be a relatively
simple patch to add the RSC field into struct ieee80211_key_conf and
fill it with the initial value in ieee80211_key_alloc(). This will waste
some memory per key, but is likely the simplest way of implementing
this.

--
Jouni Malinen PGP id EFC895FA