[RFC 0/3] WPA_NONE support in mac80211/ath9k

[RFC 0/3] WPA_NONE support in mac80211/ath9k

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

Hi,

I've tried to use WPA_NONE together with ath9k (other people reported
problems, but said it would be batman-adv related [1]). I ran into three
smaller problems and worked around them. I am not sure what kind of support
mac80211 should have for WPA_NONE, but maybe also someone else is trying
it and could use this as a reference. Nevertheless, IBSS/RSN should be
preferred.

I've used a wpa_supplicant with fixed-ibss support [2,3] on an vif configured
as adhoc device.

ap_scan=2
fast_reauth=1
	network={
	ssid="ESSID"
	mode=1
	proto=WPA
	frequency=2422
	key_mgmt=WPA-NONE
	pairwise=NONE
	group=CCMP
	psk="abcd1234"
	bssid=02:00:de:ad:be:fe
}

First problem was related in the way the decryption is done. No unicast frames
could be decrypted because the group key (the only one set for WPA_NONE)
wasn't allowed to be used for unicast decryption.

The second problem was the replay detection. Replay detection doesn't work
with WPA_NONE and therefore has to be disabled.

The third problem was the inability to set the key when no link was
established. This lead to unencrypted broadcast packets sent over the air...
not really nice. Therefore, I've just disabled the check [4] for now.

I was informed by Antonio Quartulli about the controversy to use
 !sta->sdata->u.ibss.control_port to check for for non-IBSS/RSN mode. Just
think about it is a placeholder for the imaginary function
"ieee80211_ibss_is_wpanone(...)".

Is the inability to use WPA_NONE with ath9k/mac80211 intended or just a
regression nobody noticed? In the latter case, any things which should
be changed to make the patches upstream ready?

Kind regards,
	Sven

[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-January/008895.html
[2] http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=913e3cf794cccf19d551d936a16c7d91acb5e834
[3] http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=9e2af29f9bf065099b9a2abceaf40ac0e1bf86fa
[4] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=fffd0934b9390f34bec45762192b7edd3b12b4b5

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[RFC 1/3] mac80211: Allow group key for IBSS WPA_NONE

[Sven Eckelmann]

WPA_NONE uses the shared group key to encrypt the protected frames. Therefore,
it must also be allowed for non-multicast frames to use the group key for
decryption.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/mac80211/rx.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a190895..d412fd0 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1160,7 +1160,9 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
 			if (rx->key &&
 			    rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP40 &&
 			    rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP104 &&
-			    !is_multicast_ether_addr(hdr->addr1))
+			    !is_multicast_ether_addr(hdr->addr1) &&
+			    (rx->sdata->vif.type != NL80211_IFTYPE_ADHOC ||
+			     rx->sdata->u.ibss.control_port))
 				rx->key = NULL;
 		}
 	}
-- 
1.7.10.4

[RFC 2/3] mac80211: Ignore CCMP replays for IBSS WPA_NONE

[Sven Eckelmann]

WPA_NONE has no support to avoid CCMP replays and therefore we have to disable
it in this situation to allow rejoining stations.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/mac80211/wpa.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index c175ee8..f961d9a 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -517,7 +517,9 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx)
 
 	queue = rx->security_idx;
 
-	if (memcmp(pn, key->u.ccmp.rx_pn[queue], CCMP_PN_LEN) <= 0) {
+	if (memcmp(pn, key->u.ccmp.rx_pn[queue], CCMP_PN_LEN) <= 0 &&
+	    (rx->sdata->vif.type != NL80211_IFTYPE_ADHOC ||
+	     rx->sdata->u.ibss.control_port)) {
 		key->u.ccmp.replays++;
 		return RX_DROP_UNUSABLE;
 	}
-- 
1.7.10.4

[PATCH 3/3] nl80211: Allow to set IBSS key even before IBSS_JOIN

[Sven Eckelmann]

WPA_NONE will use a shared group key for unicast and multicast. It is therefore
better to allow early setting of keys to prevent any leakage of information
through multicast frames.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
 net/wireless/nl80211.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 33de803..3fb3491 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -766,10 +766,7 @@ static int nl80211_key_allowed(struct wireless_dev *wdev)
 	case NL80211_IFTYPE_AP_VLAN:
 	case NL80211_IFTYPE_P2P_GO:
 	case NL80211_IFTYPE_MESH_POINT:
-		break;
 	case NL80211_IFTYPE_ADHOC:
-		if (!wdev->current_bss)
-			return -ENOLINK;
 		break;
 	case NL80211_IFTYPE_STATION:
 	case NL80211_IFTYPE_P2P_CLIENT:
-- 
1.7.10.4

Re: [RFC 0/3] WPA_NONE support in mac80211/ath9k

[Johannes Berg]

On Mon, 2013-01-28 at 17:11 +0100, Sven Eckelmann wrote:
> Hi,
> 
> I've tried to use WPA_NONE together with ath9k (other people reported
> problems, but said it would be batman-adv related [1]). I ran into three
> smaller problems and worked around them. I am not sure what kind of support
> mac80211 should have for WPA_NONE, but maybe also someone else is trying
> it and could use this as a reference. Nevertheless, IBSS/RSN should be
> preferred.

All of this seems really hacky. For example, instead of installing the
keys earlier, you should manage the authorized flag like in RSN IBSS.
Similarly, why not just install the same key for all stations? That way,
you probably don't even need the replay detection.

johannes

Re: Re: [RFC 0/3] WPA_NONE support in mac80211/ath9k

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

On Tuesday 29 January 2013 20:23:03 Johannes Berg wrote:
> All of this seems really hacky.

Because they are only hacks :D

But they are giving a good starting point for a discussion.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]