Skip to contentSkip to conversation

IEEE 802.11w / management frame protection

RFC PATCH In review Jouni Malinen 5 participants 38 messages Jun 17, 2008 – Aug 29, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover IEEE 802.11w / management frame protection

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.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#1 lore raw

RFC PATCH 1/7 802.11w: STA flag for MFP

Add flags for setting STA entries and struct ieee80211_if_sta to indicate whether management frame protection (MFP) is used.

net/mac80211/ieee80211_i.h +1 -0
Index: wireless-testing/net/mac80211/ieee80211_i.h
===================================================================
@@ -300,6 +300,7 @@ struct mesh_config {
 #define IEEE80211_STA_AUTO_BSSID_SEL	BIT(11)
 #define IEEE80211_STA_AUTO_CHANNEL_SEL	BIT(12)
 #define IEEE80211_STA_PRIVACY_INVOKED	BIT(13)
+#define IEEE80211_STA_MFP_ENABLED	BIT(14)
 struct ieee80211_if_sta {
 	struct timer_list timer;
 	struct work_struct work;
net/mac80211/mlme.c +6 -3
Index: wireless-testing/net/mac80211/mlme.c
===================================================================
@@ -1,6 +1,6 @@
 /*
  * BSS client mode implementation
- * Copyright 2003, Jouni Malinen <[email protected]>
+ * Copyright 2003-2008, Jouni Malinen <[email protected]>
  * Copyright 2004, Instant802 Networks, Inc.
  * Copyright 2005, Devicescape Software, Inc.
  * Copyright 2006-2007	Jiri Benc <[email protected]>
@@ -885,7 +885,7 @@ static void ieee80211_send_deauth(struct
 	skb_put(skb, 2);
 	mgmt->u.deauth.reason_code = cpu_to_le16(reason);
 
-	ieee80211_sta_tx(dev, skb, 0);
+	ieee80211_sta_tx(dev, skb, ifsta->flags & IEEE80211_STA_MFP_ENABLED);
 }
 
 
@@ -914,7 +914,7 @@ static void ieee80211_send_disassoc(stru
 	skb_put(skb, 2);
 	mgmt->u.disassoc.reason_code = cpu_to_le16(reason);
 
-	ieee80211_sta_tx(dev, skb, 0);
+	ieee80211_sta_tx(dev, skb, ifsta->flags & IEEE80211_STA_MFP_ENABLED);
 }
 
 
@@ -2107,6 +2107,9 @@ static void ieee80211_rx_mgmt_assoc_resp
 
 	rate_control_rate_init(sta, local);
 
+	if (ifsta->flags & IEEE80211_STA_MFP_ENABLED)
+		set_sta_flags(sta, WLAN_STA_MFP);
+
 	if (elems.wmm_param) {
 		set_sta_flags(sta, WLAN_STA_WME);
 		rcu_read_unlock();
include/linux/nl80211.h +2 -0
Index: wireless-testing/include/linux/nl80211.h
===================================================================
@@ -286,12 +286,14 @@ enum nl80211_iftype {
  * @NL80211_STA_FLAG_SHORT_PREAMBLE: station is capable of receiving frames
  *	with short barker preamble
  * @NL80211_STA_FLAG_WME: station is WME/QoS capable
+ * @NL80211_STA_FLAG_MFP: station uses management frame protection
  */
 enum nl80211_sta_flags {
 	__NL80211_STA_FLAG_INVALID,
 	NL80211_STA_FLAG_AUTHORIZED,
 	NL80211_STA_FLAG_SHORT_PREAMBLE,
 	NL80211_STA_FLAG_WME,
+	NL80211_STA_FLAG_MFP,
 
 	/* keep last */
 	__NL80211_STA_FLAG_AFTER_LAST,
include/net/cfg80211.h +2 -0
Index: wireless-testing/include/net/cfg80211.h
===================================================================
@@ -110,12 +110,14 @@ struct beacon_parameters {
  * @STATION_FLAG_SHORT_PREAMBLE: station is capable of receiving frames
  *	with short preambles
  * @STATION_FLAG_WME: station is WME/QoS capable
+ * @STATION_FLAG_MFP: station uses management frame protection
  */
 enum station_flags {
 	STATION_FLAG_CHANGED		= 1<<0,
 	STATION_FLAG_AUTHORIZED		= 1<<NL80211_STA_FLAG_AUTHORIZED,
 	STATION_FLAG_SHORT_PREAMBLE	= 1<<NL80211_STA_FLAG_SHORT_PREAMBLE,
 	STATION_FLAG_WME		= 1<<NL80211_STA_FLAG_WME,
+	STATION_FLAG_MFP		= 1<<NL80211_STA_FLAG_MFP,
 };
 
 /**
net/mac80211/cfg.c +4 -0
Index: wireless-testing/net/mac80211/cfg.c
===================================================================
@@ -618,6 +618,10 @@ static void sta_apply_parameters(struct 
 		sta->flags &= ~WLAN_STA_WME;
 		if (params->station_flags & STATION_FLAG_WME)
 			sta->flags |= WLAN_STA_WME;
+
+		sta->flags &= ~WLAN_STA_MFP;
+		if (params->station_flags & STATION_FLAG_MFP)
+			sta->flags |= WLAN_STA_MFP;
 		spin_unlock_bh(&sta->lock);
 	}
 
net/mac80211/debugfs_sta.c +3 -2
Index: wireless-testing/net/mac80211/debugfs_sta.c
===================================================================
@@ -74,14 +74,15 @@ static ssize_t sta_flags_read(struct fil
 	char buf[100];
 	struct sta_info *sta = file->private_data;
 	u32 staflags = get_sta_flags(sta);
-	int res = scnprintf(buf, sizeof(buf), "%s%s%s%s%s%s%s",
+	int res = scnprintf(buf, sizeof(buf), "%s%s%s%s%s%s%s%s",
 		staflags & WLAN_STA_AUTH ? "AUTH\n" : "",
 		staflags & WLAN_STA_ASSOC ? "ASSOC\n" : "",
 		staflags & WLAN_STA_PS ? "PS\n" : "",
 		staflags & WLAN_STA_AUTHORIZED ? "AUTHORIZED\n" : "",
 		staflags & WLAN_STA_SHORT_PREAMBLE ? "SHORT PREAMBLE\n" : "",
 		staflags & WLAN_STA_WME ? "WME\n" : "",
-		staflags & WLAN_STA_WDS ? "WDS\n" : "");
+		staflags & WLAN_STA_WDS ? "WDS\n" : "",
+		staflags & WLAN_STA_MFP ? "MFP\n" : "");
 	return simple_read_from_buffer(userbuf, count, ppos, buf, res);
 }
 STA_OPS(flags);
net/mac80211/sta_info.h +2 -0
Index: wireless-testing/net/mac80211/sta_info.h
===================================================================
@@ -34,6 +34,7 @@
  * @WLAN_STA_CLEAR_PS_FILT: Clear PS filter in hardware (using the
  *	IEEE80211_TX_CTL_CLEAR_PS_FILT control flag) when the next
  *	frame to this station is transmitted.
+ * @WLAN_STA_MFP: Management frame protection is used with this STA.
  */
 enum ieee80211_sta_info_flags {
 	WLAN_STA_AUTH		= 1<<0,
@@ -46,6 +47,7 @@ enum ieee80211_sta_info_flags {
 	WLAN_STA_WDS		= 1<<7,
 	WLAN_STA_PSPOLL		= 1<<8,
 	WLAN_STA_CLEAR_PS_FILT	= 1<<9,
+	WLAN_STA_MFP		= 1<<10,
 };
 
 #define STA_TID_NUM 16

--

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#2 lore raw

RFC PATCH 2/7 802.11w: CCMP for management frames

In reply to Jouni Malinen

Extend CCMP to support encryption and decryption of unicast management frames.

net/mac80211/wpa.c +11 -5
Index: wireless-testing/net/mac80211/wpa.c
===================================================================
@@ -299,7 +299,7 @@ static void ccmp_special_blocks(struct s
 				int encrypted)
 {
 	u16 fc;
-	int a4_included, qos_included;
+	int a4_included, qos_included, mgmt;
 	u8 qos_tid, *fc_pos, *data, *sa, *da;
 	int len_a;
 	size_t data_len;
@@ -309,6 +309,7 @@ static void ccmp_special_blocks(struct s
 	fc = fc_pos[0] ^ (fc_pos[1] << 8);
 	a4_included = (fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) ==
 		(IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS);
+	mgmt = (fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_MGMT;
 
 	ieee80211_get_hdr_info(skb, &sa, &da, &qos_tid, &data, &data_len);
 	data_len -= CCMP_HDR_LEN + (encrypted ? CCMP_MIC_LEN : 0);
@@ -320,8 +321,10 @@ static void ccmp_special_blocks(struct s
 	/* First block, b_0 */
 
 	b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
-	/* Nonce: QoS Priority | A2 | PN */
-	b_0[1] = qos_tid;
+	/* Nonce: Nonce Flags | A2 | PN
+	 * Nonce Flags: Priority (b0..b3) | Management (b4) | Reserved (b5..b7)
+	 */
+	b_0[1] = qos_tid | (mgmt << 4);
 	memcpy(&b_0[2], hdr->addr2, 6);
 	memcpy(&b_0[8], pn, CCMP_PN_LEN);
 	/* l(m) */
@@ -338,8 +341,11 @@ static void ccmp_special_blocks(struct s
 
 	aad[0] = 0; /* (len_a >> 8) & 0xff; */
 	aad[1] = len_a & 0xff;
-	/* Mask FC: zero subtype b4 b5 b6 */
-	aad[2] = fc_pos[0] & ~(BIT(4) | BIT(5) | BIT(6));
+	aad[2] = fc_pos[0]; /* FC type/subtype */
+	if (!mgmt) {
+		/* Mask FC: zero subtype b4 b5 b6 */
+		aad[2] &= BIT(4) | BIT(5) | BIT(6);
+	}
 	/* Retry, PwrMgt, MoreData; set Protected */
 	aad[3] = (fc_pos[1] & ~(BIT(3) | BIT(4) | BIT(5))) | BIT(6);
 	memcpy(&aad[4], &hdr->addr1, 18);
net/mac80211/tx.c +25 -1
Index: wireless-testing/net/mac80211/tx.c
===================================================================
@@ -446,6 +446,26 @@ ieee80211_tx_h_ps_buf(struct ieee80211_t
 		return ieee80211_tx_h_multicast_ps_buf(tx);
 }
 
+static int ieee80211_use_mfp(u16 fc, struct sta_info *sta, struct sk_buff *skb)
+{
+	u16 stype;
+
+	if ((fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT)
+		return 0;
+
+	if (sta == NULL || !test_sta_flags(sta, WLAN_STA_MFP))
+		return 0;
+
+	stype = fc & IEEE80211_FCTL_STYPE;
+	if (stype != IEEE80211_STYPE_DEAUTH &&
+	    stype != IEEE80211_STYPE_DISASSOC &&
+	    stype != IEEE80211_STYPE_ACTION)
+		return 0;
+
+	return 1;
+}
+
+
 static ieee80211_tx_result
 ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
 {
@@ -482,10 +502,14 @@ ieee80211_tx_h_select_key(struct ieee802
 			    stype == IEEE80211_STYPE_AUTH)
 				break;
 		case ALG_TKIP:
-		case ALG_CCMP:
 			if (!WLAN_FC_DATA_PRESENT(fc))
 				tx->key = NULL;
 			break;
+		case ALG_CCMP:
+			if (!WLAN_FC_DATA_PRESENT(fc) &&
+			    !ieee80211_use_mfp(fc, tx->sta, tx->skb))
+				tx->key = NULL;
+			break;
 		}
 	}
 

--

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#3 lore raw

RFC PATCH 3/7 802.11w: Add BIP (AES-128-CMAC)

In reply to Jouni Malinen

Implement Broadcast/Multicast Integrity Protocol for management frame protection. This patch adds the needed definitions for the new information element (MMIE) and implementation for the new "encryption" type (though, BIP is actually not encrypting data, it provides only integrity protection). These routines will be used by a follow-on patch that enables BIP for multicast/broadcast robust management frames.

include/linux/ieee80211.h +10 -0
Index: wireless-testing/include/linux/ieee80211.h
===================================================================
@@ -590,6 +590,15 @@ struct ieee80211_mgmt {
 } __attribute__ ((packed));
 
 
+/* Management MIC information element (IEEE 802.11w) */
+struct ieee80211_mmie {
+	u8 element_id;
+	u8 length;
+	u8 key_id[2]; /* little endian, but may be unaligned */
+	u8 sequence_number[6];
+	u8 mic[8];
+} __attribute__ ((packed));
+
 /* Control frames */
 struct ieee80211_rts {
 	__le16 frame_control;
@@ -860,6 +869,7 @@ enum ieee80211_eid {
 	WLAN_EID_HT_EXTRA_INFO = 61,
 	/* 802.11i */
 	WLAN_EID_RSN = 48,
+	WLAN_EID_MMIE = 76 /* 802.11w */,
 	WLAN_EID_WPA = 221,
 	WLAN_EID_GENERIC = 221,
 	WLAN_EID_VENDOR_SPECIFIC = 221,
net/mac80211/key.h +10 -0
Index: wireless-testing/net/mac80211/key.h
===================================================================
@@ -109,6 +109,16 @@ struct ieee80211_key {
 			u8 tx_crypto_buf[6 * AES_BLOCK_LEN];
 			u8 rx_crypto_buf[6 * AES_BLOCK_LEN];
 		} ccmp;
+		struct {
+			u8 tx_pn[6];
+			u8 rx_pn[6];
+			struct crypto_cipher *tfm;
+			u32 replays; /* dot11RSNAStatsCMACReplays */
+			u32 icverrors; /* dot11RSNAStatsCMACICVErrors */
+			/* scratch buffers for virt_to_page() (crypto API) */
+			u8 tx_crypto_buf[2 * AES_BLOCK_LEN];
+			u8 rx_crypto_buf[2 * AES_BLOCK_LEN];
+		} aes_cmac;
 	} u;
 
 	/* number of times this key has been used */
net/mac80211/wpa.c +129 -0

149 lines not on this page · raw message

net/mac80211/wpa.h +5 -0
Index: wireless-testing/net/mac80211/wpa.h
===================================================================
@@ -28,4 +28,9 @@ ieee80211_crypto_ccmp_encrypt(struct iee
 ieee80211_rx_result
 ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx);
 
+ieee80211_tx_result
+ieee80211_crypto_aes_cmac_encrypt(struct ieee80211_tx_data *tx);
+ieee80211_rx_result
+ieee80211_crypto_aes_cmac_decrypt(struct ieee80211_rx_data *rx);
+
 #endif /* WPA_H */
net/mac80211/aes_cmac.c new file +135 -0

135 lines not on this page · raw message

net/mac80211/aes_cmac.h new file +19 -0
Index: wireless-testing/net/mac80211/aes_cmac.h
===================================================================
@@ -0,0 +1,19 @@
+/*
+ * Copyright 2008, Jouni Malinen <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef AES_CMAC_H
+#define AES_CMAC_H
+
+#include <linux/crypto.h>
+
+struct crypto_cipher * ieee80211_aes_cmac_key_setup(const u8 key[]);
+void ieee80211_aes_cmac(struct crypto_cipher *tfm, u8 *scratch, const u8 *aad,
+			const u8 *data, size_t data_len, u8 *mic);
+void ieee80211_aes_cmac_key_free(struct crypto_cipher *tfm);
+
+#endif /* AES_CMAC_H */
net/mac80211/Makefile +1 -0
Index: wireless-testing/net/mac80211/Makefile
===================================================================
@@ -21,6 +21,7 @@ mac80211-y := \
 	michael.o \
 	tkip.o \
 	aes_ccm.o \
+	aes_cmac.o \
 	cfg.o \
 	rx.o \
 	tx.o \

--

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#4 lore raw

Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

include/linux/ieee80211.h struct ieee80211_mgmt { · line 597

Quoted 6 lines
include/linux/ieee80211.h +5 -0
+/* Management MIC information element (IEEE 802.11w) */
+struct ieee80211_mmie {
+	u8 element_id;
+	u8 length;
+	u8 key_id[2]; /* little endian, but may be unaligned */

Since you say the struct is packed you should be able to use __le16 just fine.

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 600

Quoted 1 line
net/mac80211/wpa.c +1 -0
+	if ((tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)) {

I think one set of parentheses suffices ;)

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 611

Quoted 6 lines
net/mac80211/wpa.c +6 -0
+	if (skb_tailroom(skb) < sizeof(*mmie)) {
+		if (pskb_expand_head(skb, skb_headroom(skb),
+				     skb_tailroom(skb) + sizeof((*mmie)),
+				     GFP_ATOMIC) < 0)
+			return TX_DROP;
+	}

I tried ensure pskb_expand_head is only called at most once when the frame is handed to master_start_xmit to avoid problems with skb truesize and such. Could you add the necessary space at that point already, possibly simply reserving max(mmic-len, mmie-len) or so instead of the current mmic-len (I think)? I'd hate to add back calls to pskb_expand_head at other places, and it's only 18 bytes so not really huge.

Review

Quoted 2 lines
(quoted diff) +2 -0
+	if ((rx->fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT)
+		return RX_CONTINUE;

Harvey just added a bunch of helper inlines to include/linux/ieee80211.h for stuff like that, I think you could use one of them here.

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 662

Quoted 5 lines
net/mac80211/wpa.c +5 -0
+       mmie = (struct ieee80211_mmie *)
+               (skb->data + skb->len - sizeof(*mmie));
+       if (mmie->element_id != WLAN_EID_MMIE ||
+           mmie->length != sizeof(*mmie) - 2)
+               return RX_DROP_UNUSABLE; /* Invalid MMIE */

Is that what the draft says? Because iterating the IEs would be different, this means you could potentially have something like a vendor IE last that encapsulates the MMIE including type/len fields, which should probably not be used?

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 686

Quoted 2 lines
net/mac80211/wpa.c +2 -0
+	/* Remove MMIE */
+	skb_trim(skb, skb->len - sizeof(*mmie));

Is that actually necessary? Since it's an IE, it should be ignored by all other code, no? Not that it matters though.

johannes

#5 lore raw

Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

Quoted 5 lines · Johannes Berg

Review

Quoted 2 lines
(quoted diff) +2 -0
+	if ((rx->fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT)
+		return RX_CONTINUE;

Harvey just added a bunch of helper inlines to include/linux/ieee80211.h for stuff like that, I think you could use one of them here.

Afraid not, rx->fc is a u16. The helpers are all for __le16.

Harvey

#6 lore raw

Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

In reply to Johannes Berg
Quoted 8 lines · Johannes Berg

include/linux/ieee80211.h struct ieee80211_mgmt { · line 597

Quoted 5 lines
include/linux/ieee80211.h +5 -0
+/* Management MIC information element (IEEE 802.11w) */
+struct ieee80211_mmie {
+	u8 element_id;
+	u8 length;
+	u8 key_id[2]; /* little endian, but may be unaligned */

Since you say the struct is packed you should be able to use __le16 just fine.

Is that guaranteed to force all accesses of the field to not use 16-bit read/write?

Quoted 3 lines

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 600

Quoted 1 line
net/mac80211/wpa.c +1 -0
+	if ((tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)) {

I think one set of parentheses suffices ;)

Aah.. That's a copy-paste from something old.. I think I removed the IEEE80211_KEY_FLAG_GENERATE_IV flag from here for BIP.. I'm not completely sure yet, how we should have this, i.e., whether that flag should be used here or not. It is unclear what type of hwaccel, if any, vendors are going to implement for BIP.

Quoted 7 lines

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 611

Quoted 6 lines
net/mac80211/wpa.c +6 -0
+	if (skb_tailroom(skb) < sizeof(*mmie)) {
+		if (pskb_expand_head(skb, skb_headroom(skb),
+				     skb_tailroom(skb) + sizeof((*mmie)),
+				     GFP_ATOMIC) < 0)
+			return TX_DROP;
+	}
Quoted 7 lines

I tried ensure pskb_expand_head is only called at most once when the frame is handed to master_start_xmit to avoid problems with skb truesize and such. Could you add the necessary space at that point already, possibly simply reserving max(mmic-len, mmie-len) or so instead of the current mmic-len (I think)? I'd hate to add back calls to pskb_expand_head at other places, and it's only 18 bytes so not really huge.

I thought about that for a moment, but then decided that it would be okay to just do this here since MMIE is larger than any other tailroom we have and there is next to no real use for multicast/broadcast management frames, so there is no need to optimize this. I don't see how this would require any other place to use pskb_expand_head.

Anyway, I would assume it would be possible to do this by changing IEEE80211_ENCRYPT_TAILROOM from 12 to 22 which would waste 10 bytes extra for every frame (well, not waste for BIP-protected frames but there are next to none of them).

Quoted 5 lines

Review

Quoted 2 lines
(quoted diff) +2 -0
+	if ((rx->fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT)
+		return RX_CONTINUE;

Harvey just added a bunch of helper inlines to include/linux/ieee80211.h for stuff like that, I think you could use one of them here.

I converted some of the places to use the new helpers, but did not go through all places. I would assume there is still places that can be made to use them, but as long as FC is available in host byte order, it is easier and faster to use it. Sure, if rx->fc were to disappear, that may make it more likely that these get changed ;-).

Quoted 10 lines

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 662

Quoted 5 lines
net/mac80211/wpa.c +5 -0
+       mmie = (struct ieee80211_mmie *)
+               (skb->data + skb->len - sizeof(*mmie));
+       if (mmie->element_id != WLAN_EID_MMIE ||
+           mmie->length != sizeof(*mmie) - 2)
+               return RX_DROP_UNUSABLE; /* Invalid MMIE */

Is that what the draft says? Because iterating the IEs would be different, this means you could potentially have something like a vendor IE last that encapsulates the MMIE including type/len fields, which should probably not be used?

MMIE has to be the last "IE" in the frame. Sure, it would, in theory, be possible to receive a frame that does not have MMIE, but has "MMIE like" data in another IE. As long as we can make sure that this is reached only for frames that are received from MFP enabled AP, the simple solution of pointing to the end of the frame is enough. Otherwise, we would need to parse all the IEs and know about the start of IEs in all different types of Action frames.. That's not really something I would like to do.

Quoted 5 lines

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 686

Quoted 2 lines
net/mac80211/wpa.c +2 -0
+	/* Remove MMIE */
+	skb_trim(skb, skb->len - sizeof(*mmie));

Is that actually necessary? Since it's an IE, it should be ignored by all other code, no? Not that it matters though.

I don't think it is necessary in the sense that leaving the "IE" in would break anything. However, I do think this is the correct thing to do here and matches with what we do with TKIP/CCMP. MMIE is not really an IE, it is just a frame component that is made to look like one. The current IEEE 802.11w draft is bit confused about what MMIE is at places, but anyway, I would compare it to TKIP ICV and CCMP MIC in the end of the frames.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#7 lore raw

Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

Quoted 5 lines · On Tuesday 17 June 2008 20:06:10 Jouni Malinen wrote:
Quoted 2 lines

Since you say the struct is packed you should be able to use __le16 just fine.

Is that guaranteed to force all accesses of the field to not use 16-bit read/write?

Yes.

Signature · 1 line
Greetings Michael.
maintainer
#8 lore raw

Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

In reply to Jouni Malinen
Quoted 6 lines

Aah.. That's a copy-paste from something old.. I think I removed the IEEE80211_KEY_FLAG_GENERATE_IV flag from here for BIP.. I'm not completely sure yet, how we should have this, i.e., whether that flag should be used here or not. It is unclear what type of hwaccel, if any, vendors are going to implement for BIP.

Yeah, good point, I guess we should just not implement hwaccel until we find hardware that can handle it.

Quoted 8 lines
Quoted 7 lines

I tried ensure pskb_expand_head is only called at most once when the frame is handed to master_start_xmit to avoid problems with skb truesize and such. Could you add the necessary space at that point already, possibly simply reserving max(mmic-len, mmie-len) or so instead of the current mmic-len (I think)? I'd hate to add back calls to pskb_expand_head at other places, and it's only 18 bytes so not really huge.

Quoted 5 lines

I thought about that for a moment, but then decided that it would be okay to just do this here since MMIE is larger than any other tailroom we have and there is next to no real use for multicast/broadcast management frames, so there is no need to optimize this. I don't see how this would require any other place to use pskb_expand_head.

Well the thing is that you can't just call pskb_expand_head without orphaning the SKB first and all that truesize adjusting, because of truesize accounting, because it might now or later belong to a userspace socket.

Quoted 4 lines

Anyway, I would assume it would be possible to do this by changing IEEE80211_ENCRYPT_TAILROOM from 12 to 22 which would waste 10 bytes extra for every frame (well, not waste for BIP-protected frames but there are next to none of them).

22? Is there something else on the frame in addition to the MMIE?

Quoted 5 lines

I converted some of the places to use the new helpers, but did not go through all places. I would assume there is still places that can be made to use them, but as long as FC is available in host byte order, it is easier and faster to use it. Sure, if rx->fc were to disappear, that may make it more likely that these get changed ;-).

Heh, ok, that's fine, I didn't realise that it was using the CPU order FC.

Quoted 5 lines
Quoted 4 lines

Is that what the draft says? Because iterating the IEs would be different, this means you could potentially have something like a vendor IE last that encapsulates the MMIE including type/len fields, which should probably not be used?

Quoted 8 lines

MMIE has to be the last "IE" in the frame. Sure, it would, in theory, be possible to receive a frame that does not have MMIE, but has "MMIE like" data in another IE. As long as we can make sure that this is reached only for frames that are received from MFP enabled AP, the simple solution of pointing to the end of the frame is enough. Otherwise, we would need to parse all the IEs and know about the start of IEs in all different types of Action frames.. That's not really something I would like to do.

Yeah, true, and we actually have that in another place too. If we then remove the MMIE, the IE sanity checks should catch the bad frame anyway, when/if it is parsed. Except we removed those because APs were sending bogus information. I'm fine with this, but we should be aware of the consequence.

Quoted 6 lines
Quoted 5 lines

net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 686

Quoted 2 lines
net/mac80211/wpa.c +2 -0
+	/* Remove MMIE */
+	skb_trim(skb, skb->len - sizeof(*mmie));

Is that actually necessary? Since it's an IE, it should be ignored by all other code, no? Not that it matters though.

Quoted 7 lines

I don't think it is necessary in the sense that leaving the "IE" in would break anything. However, I do think this is the correct thing to do here and matches with what we do with TKIP/CCMP. MMIE is not really an IE, it is just a frame component that is made to look like one. The current IEEE 802.11w draft is bit confused about what MMIE is at places, but anyway, I would compare it to TKIP ICV and CCMP MIC in the end of the frames.

Works for me.

johannes

#9 lore raw

Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

Quoted 4 lines · Johannes Berg

Well the thing is that you can't just call pskb_expand_head without orphaning the SKB first and all that truesize adjusting, because of truesize accounting, because it might now or later belong to a userspace socket.

OK. I don't want to do that here, so I'll see what can be done with IEEE80211_ENCRYPT_TAILROOM.

Quoted 6 lines
Quoted 4 lines

Anyway, I would assume it would be possible to do this by changing IEEE80211_ENCRYPT_TAILROOM from 12 to 22 which would waste 10 bytes extra for every frame (well, not waste for BIP-protected frames but there are next to none of them).

22? Is there something else on the frame in addition to the MMIE?

Uhm.. Maybe I just cannot count anymore.. Or well, I did not remember where the 12 comes from and decided to add 4 because of that. Anyway, yes, now that I see that 12 is 8(MIC)+4(ICV) for TKIP, this 12 would indeed change to 18.

Quoted 5 lines

Yeah, true, and we actually have that in another place too. If we then remove the MMIE, the IE sanity checks should catch the bad frame anyway, when/if it is parsed. Except we removed those because APs were sending bogus information. I'm fine with this, but we should be aware of the consequence.

As long as we get the RX path implemented properly, this will only hit if there is a bug in an MFP-enabled AP or someone is trying to attack the network and both cases are very good candidates for dropping the frame anyway. The key selection is supposed to pick BIP key only if the sender (AP) has negotiated MFP and as such, all valid broadcast robust management frames are guaranteed to have MMIE in the end.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#10 lore raw

Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

Quoted 7 lines
Quoted 6 lines

Yeah, true, and we actually have that in another place too. If we then remove the MMIE, the IE sanity checks should catch the bad frame anyway, when/if it is parsed. Except we removed those because APs were sending bogus information. I'm fine with this, but we should be aware of the consequence.

Quoted 6 lines

As long as we get the RX path implemented properly, this will only hit if there is a bug in an MFP-enabled AP or someone is trying to attack the network and both cases are very good candidates for dropping the frame anyway. The key selection is supposed to pick BIP key only if the sender (AP) has negotiated MFP and as such, all valid broadcast robust management frames are guaranteed to have MMIE in the end.

True. I was more thinking of somebody intentionally doing it in the AP to implement "802.11w in vendor IEs" or something like that but I guess that's unlikely to happen. And yeah, an attack won't work anyway since those frames would be rejected based on the wrong MIC.

johannes

#11 lore raw

RFC PATCH 4/7 802.11w: Use BIP (AES-128-CMAC)

In reply to Jouni Malinen

Add mechanism for managing BIP keys (IGTK) and integrate BIP into the TX/RX paths.

include/linux/ieee80211.h +1 -0
Index: wireless-testing/include/linux/ieee80211.h
===================================================================
@@ -909,6 +909,7 @@ enum ieee80211_back_parties {
 /* reserved: 				0x000FAC03 */
 #define WLAN_CIPHER_SUITE_CCMP		0x000FAC04
 #define WLAN_CIPHER_SUITE_WEP104	0x000FAC05
+#define WLAN_CIPHER_SUITE_AES_CMAC	0x000FAC06
 
 #define WLAN_MAX_KEY_LEN		32
 
include/net/mac80211.h +2 -0
Index: wireless-testing/include/net/mac80211.h
===================================================================
@@ -550,11 +550,13 @@ struct ieee80211_if_conf {
  * @ALG_WEP: WEP40 or WEP104
  * @ALG_TKIP: TKIP
  * @ALG_CCMP: CCMP (AES)
+ * @ALG_AES_CMAC: AES-128-CMAC
  */
 enum ieee80211_key_alg {
 	ALG_WEP,
 	ALG_TKIP,
 	ALG_CCMP,
+	ALG_AES_CMAC,
 };
 
 
net/mac80211/cfg.c +31 -0
Index: wireless-testing/net/mac80211/cfg.c
===================================================================
@@ -156,6 +156,9 @@ static int ieee80211_add_key(struct wiph
 	case WLAN_CIPHER_SUITE_CCMP:
 		alg = ALG_CCMP;
 		break;
+	case WLAN_CIPHER_SUITE_AES_CMAC:
+		alg = ALG_AES_CMAC;
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -296,6 +299,17 @@ static int ieee80211_get_key(struct wiph
 		else
 			params.cipher = WLAN_CIPHER_SUITE_WEP104;
 		break;
+	case ALG_AES_CMAC:
+		params.cipher = WLAN_CIPHER_SUITE_AES_CMAC;
+		seq[0] = key->u.aes_cmac.tx_pn[5];
+		seq[1] = key->u.aes_cmac.tx_pn[4];
+		seq[2] = key->u.aes_cmac.tx_pn[3];
+		seq[3] = key->u.aes_cmac.tx_pn[2];
+		seq[4] = key->u.aes_cmac.tx_pn[1];
+		seq[5] = key->u.aes_cmac.tx_pn[0];
+		params.seq = seq;
+		params.seq_len = 6;
+		break;
 	}
 
 	params.key = key->conf.key;
@@ -325,6 +339,22 @@ static int ieee80211_config_default_key(
 	return 0;
 }
 
+static int ieee80211_config_default_mgmt_key(struct wiphy *wiphy,
+					     struct net_device *dev,
+					     u8 key_idx)
+{
+	struct ieee80211_sub_if_data *sdata;
+
+	rcu_read_lock();
+
+	sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	ieee80211_set_default_mgmt_key(sdata, key_idx);
+
+	rcu_read_unlock();
+
+	return 0;
+}
+
 static void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
 {
 	struct ieee80211_sub_if_data *sdata = sta->sdata;
@@ -964,6 +994,7 @@ struct cfg80211_ops mac80211_config_ops 
 	.del_key = ieee80211_del_key,
 	.get_key = ieee80211_get_key,
 	.set_default_key = ieee80211_config_default_key,
+	.set_default_mgmt_key = ieee80211_config_default_mgmt_key,
 	.add_beacon = ieee80211_add_beacon,
 	.set_beacon = ieee80211_set_beacon,
 	.del_beacon = ieee80211_del_beacon,
net/mac80211/debugfs_key.c +77 -2

126 lines not on this page · raw message

net/mac80211/key.h +6 -0
Index: wireless-testing/net/mac80211/key.h
===================================================================
@@ -59,6 +59,8 @@ struct sta_info;
  *	acceleration.
  * @KEY_FLAG_TODO_DEFKEY: Key is default key and debugfs needs to be updated.
  * @KEY_FLAG_TODO_ADD_DEBUGFS: Key needs to be added to debugfs.
+ * @KEY_FLAG_TODO_DEFMGMTKEY: Key is default management key and debugfs needs
+ *	to be updated.
  */
 enum ieee80211_internal_key_flags {
 	KEY_FLAG_UPLOADED_TO_HARDWARE	= BIT(0),
@@ -67,6 +69,7 @@ enum ieee80211_internal_key_flags {
 	KEY_FLAG_TODO_HWACCEL_REMOVE	= BIT(3),
 	KEY_FLAG_TODO_DEFKEY		= BIT(4),
 	KEY_FLAG_TODO_ADD_DEBUGFS	= BIT(5),
+	KEY_FLAG_TODO_DEFMGMTKEY	= BIT(6),
 };
 
 struct tkip_ctx {
@@ -137,6 +140,7 @@ struct ieee80211_key {
 		struct dentry *tx_spec;
 		struct dentry *rx_spec;
 		struct dentry *replays;
+		struct dentry *icverrors;
 		struct dentry *key;
 		struct dentry *ifindex;
 		int cnt;
@@ -163,6 +167,8 @@ void ieee80211_key_link(struct ieee80211
 			struct sta_info *sta);
 void ieee80211_key_free(struct ieee80211_key *key);
 void ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata, int idx);
+void ieee80211_set_default_mgmt_key(struct ieee80211_sub_if_data *sdata,
+				    int idx);
 void ieee80211_free_keys(struct ieee80211_sub_if_data *sdata);
 void ieee80211_enable_keys(struct ieee80211_sub_if_data *sdata);
 void ieee80211_disable_keys(struct ieee80211_sub_if_data *sdata);
net/mac80211/rx.c +94 -9

155 lines not on this page · raw message

net/mac80211/tx.c +10 -0
Index: wireless-testing/net/mac80211/tx.c
===================================================================
@@ -477,6 +477,9 @@ ieee80211_tx_h_select_key(struct ieee802
 		tx->key = NULL;
 	else if (tx->sta && (key = rcu_dereference(tx->sta->key)))
 		tx->key = key;
+	else if ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_MGMT &&
+		 (key = rcu_dereference(tx->sdata->default_mgmt_key)))
+		tx->key = key;
 	else if ((key = rcu_dereference(tx->sdata->default_key)))
 		tx->key = key;
 	else if (tx->sdata->drop_unencrypted &&
@@ -510,6 +513,11 @@ ieee80211_tx_h_select_key(struct ieee802
 			    !ieee80211_use_mfp(fc, tx->sta, tx->skb))
 				tx->key = NULL;
 			break;
+		case ALG_AES_CMAC:
+			if ((fc & IEEE80211_FCTL_FTYPE) !=
+			    IEEE80211_FTYPE_MGMT)
+				tx->key = NULL;
+			break;
 		}
 	}
 
@@ -771,6 +779,8 @@ ieee80211_tx_h_encrypt(struct ieee80211_
 		return ieee80211_crypto_tkip_encrypt(tx);
 	case ALG_CCMP:
 		return ieee80211_crypto_ccmp_encrypt(tx);
+	case ALG_AES_CMAC:
+		return ieee80211_crypto_aes_cmac_encrypt(tx);
 	}
 
 	/* not reached */
net/mac80211/key.c +56 -2

125 lines not on this page · raw message

net/mac80211/ieee80211_i.h +4 -1
Index: wireless-testing/net/mac80211/ieee80211_i.h
===================================================================
@@ -429,8 +429,10 @@ struct ieee80211_sub_if_data {
 	unsigned int fragment_next;
 
 #define NUM_DEFAULT_KEYS 4
-	struct ieee80211_key *keys[NUM_DEFAULT_KEYS];
+#define NUM_DEFAULT_MGMT_KEYS 2
+	struct ieee80211_key *keys[NUM_DEFAULT_KEYS + NUM_DEFAULT_MGMT_KEYS];
 	struct ieee80211_key *default_key;
+	struct ieee80211_key *default_mgmt_key;
 
 	/*
 	 * BSS configuration for this interface.
@@ -492,6 +494,7 @@ struct ieee80211_sub_if_data {
 			struct dentry *mode;
 		} monitor;
 		struct dentry *default_key;
+		struct dentry *default_mgmt_key;
 	} debugfs;
 
 #ifdef CONFIG_MAC80211_MESH
include/net/cfg80211.h +5 -0
Index: wireless-testing/include/net/cfg80211.h
===================================================================
@@ -306,6 +306,8 @@ struct wiphy;
  *
  * @set_default_key: set the default key on an interface
  *
+ * @set_default_mgmt_key: set the default management frame key on an interface
+ *
  * @add_beacon: Add a beacon with given parameters, @head, @interval
  *	and @dtim_period will be valid, @tail is optional.
  * @set_beacon: Change the beacon parameters for an access point mode
@@ -341,6 +343,9 @@ struct cfg80211_ops {
 	int	(*set_default_key)(struct wiphy *wiphy,
 				   struct net_device *netdev,
 				   u8 key_index);
+	int	(*set_default_mgmt_key)(struct wiphy *wiphy,
+					struct net_device *netdev,
+					u8 key_index);
 
 	int	(*add_beacon)(struct wiphy *wiphy, struct net_device *dev,
 			      struct beacon_parameters *info);
net/mac80211/debugfs_key.h +10 -0
Index: wireless-testing/net/mac80211/debugfs_key.h
===================================================================
@@ -6,6 +6,10 @@ void ieee80211_debugfs_key_add(struct ie
 void ieee80211_debugfs_key_remove(struct ieee80211_key *key);
 void ieee80211_debugfs_key_add_default(struct ieee80211_sub_if_data *sdata);
 void ieee80211_debugfs_key_remove_default(struct ieee80211_sub_if_data *sdata);
+void ieee80211_debugfs_key_add_mgmt_default(
+	struct ieee80211_sub_if_data *sdata);
+void ieee80211_debugfs_key_remove_mgmt_default(
+	struct ieee80211_sub_if_data *sdata);
 void ieee80211_debugfs_key_sta_del(struct ieee80211_key *key,
 				   struct sta_info *sta);
 #else
@@ -19,6 +23,12 @@ static inline void ieee80211_debugfs_key
 static inline void ieee80211_debugfs_key_remove_default(
 	struct ieee80211_sub_if_data *sdata)
 {}
+static inline void ieee80211_debugfs_key_add_mgmt_default(
+	struct ieee80211_sub_if_data *sdata)
+{}
+static inline void ieee80211_debugfs_key_remove_mgmt_default(
+	struct ieee80211_sub_if_data *sdata)
+{}
 static inline void ieee80211_debugfs_key_sta_del(struct ieee80211_key *key,
 						 struct sta_info *sta)
 {}
net/wireless/nl80211.c +21 -7
Index: wireless-testing/net/wireless/nl80211.c
===================================================================
@@ -87,6 +87,8 @@ static struct nla_policy nl80211_policy[
 	[NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
 				.len = IEEE80211_MAX_MESH_ID_LEN },
 	[NL80211_ATTR_MPATH_NEXT_HOP] = { .type = NLA_U32 },
+
+	[NL80211_ATTR_KEY_DEFAULT_MGMT] = { .type = NLA_FLAG },
 };
 
 /* message building helper */
@@ -537,7 +539,7 @@ static int nl80211_get_key(struct sk_buf
 	if (info->attrs[NL80211_ATTR_KEY_IDX])
 		key_idx = nla_get_u8(info->attrs[NL80211_ATTR_KEY_IDX]);
 
-	if (key_idx > 3)
+	if (key_idx > 5)
 		return -EINVAL;
 
 	if (info->attrs[NL80211_ATTR_MAC])
@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_buf
 	int err;
 	struct net_device *dev;
 	u8 key_idx;
+	int (*func)(struct wiphy *wiphy, struct net_device *netdev,
+		    u8 key_index);
 
 	if (!info->attrs[NL80211_ATTR_KEY_IDX])
 		return -EINVAL;
 
 	key_idx = nla_get_u8(info->attrs[NL80211_ATTR_KEY_IDX]);
 
-	if (key_idx > 3)
+	if (key_idx > 5)
 		return -EINVAL;
 
 	/* currently only support setting default key */
-	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT])
+	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT] &&
+	    !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT])
 		return -EINVAL;
 
 	err = get_drv_dev_by_info_ifindex(info, &drv, &dev);
 	if (err)
 		return err;
 
-	if (!drv->ops->set_default_key) {
+	if (info->attrs[NL80211_ATTR_KEY_DEFAULT])
+		func = drv->ops->set_default_key;
+	else
+		func = drv->ops->set_default_mgmt_key;
+
+	if (!func) {
 		err = -EOPNOTSUPP;
 		goto out;
 	}
 
 	rtnl_lock();
-	err = drv->ops->set_default_key(&drv->wiphy, dev, key_idx);
+	err = func(&drv->wiphy, dev, key_idx);
 	rtnl_unlock();
 
  out:
@@ -662,7 +672,7 @@ static int nl80211_new_key(struct sk_buf
 	if (info->attrs[NL80211_ATTR_MAC])
 		mac_addr = nla_data(info->attrs[NL80211_ATTR_MAC]);
 
-	if (key_idx > 3)
+	if (key_idx > 5)
 		return -EINVAL;
 
 	/*
@@ -693,6 +703,10 @@ static int nl80211_new_key(struct sk_buf
 		if (params.key_len != 13)
 			return -EINVAL;
 		break;
+	case WLAN_CIPHER_SUITE_AES_CMAC:
+		if (params.key_len != 16)
+			return -EINVAL;
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -727,7 +741,7 @@ static int nl80211_del_key(struct sk_buf
 	if (info->attrs[NL80211_ATTR_KEY_IDX])
 		key_idx = nla_get_u8(info->attrs[NL80211_ATTR_KEY_IDX]);
 
-	if (key_idx > 3)
+	if (key_idx > 5)
 		return -EINVAL;
 
 	if (info->attrs[NL80211_ATTR_MAC])
include/linux/nl80211.h +4 -2
Index: wireless-testing/include/linux/nl80211.h
===================================================================
@@ -51,8 +51,8 @@
  *
  * @NL80211_CMD_GET_KEY: Get sequence counter information for a key specified
  *	by %NL80211_ATTR_KEY_IDX and/or %NL80211_ATTR_MAC.
- * @NL80211_CMD_SET_KEY: Set key attributes %NL80211_ATTR_KEY_DEFAULT or
- *	%NL80211_ATTR_KEY_THRESHOLD.
+ * @NL80211_CMD_SET_KEY: Set key attributes %NL80211_ATTR_KEY_DEFAULT,
+ *	%NL80211_ATTR_KEY_DEFAULT_MGMT, or %NL80211_ATTR_KEY_THRESHOLD.
  * @NL80211_CMD_NEW_KEY: add a key with given %NL80211_ATTR_KEY_DATA,
  *	%NL80211_ATTR_KEY_IDX, %NL80211_ATTR_MAC and %NL80211_ATTR_KEY_CIPHER
  *	attributes.
@@ -235,6 +235,8 @@ enum nl80211_attrs {
 	NL80211_ATTR_MPATH_NEXT_HOP,
 	NL80211_ATTR_MPATH_INFO,
 
+	NL80211_ATTR_KEY_DEFAULT_MGMT,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,

--

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#12 lore raw

Re: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)

Quoted 12 lines
net/wireless/nl80211.c +2 -0
@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_buf
 	int err;
 	struct net_device *dev;
 	u8 key_idx;
+	int (*func)(struct wiphy *wiphy, struct net_device *netdev,
+		    u8 key_index);
 
 	if (!info->attrs[NL80211_ATTR_KEY_IDX])
 		return -EINVAL;
 
 	key_idx = nla_get_u8(info->attrs[NL80211_ATTR_KEY_IDX]);

net/wireless/nl80211.c static int nl80211_set_key(struct sk_buf · line 622

Quoted 10 lines
net/wireless/nl80211.c +3 -2
 
-	if (key_idx > 3)
+	if (key_idx > 5)
 		return -EINVAL;
 
 	/* currently only support setting default key */
-	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT])
+	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT] &&
+	    !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT])
 		return -EINVAL;

I think this should probably check the key index depending on the type, i.e. only permit 4 and 5 for mgmt and 0-3 for data keys.

johannes

#13 lore raw

Re: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)

Quoted 11 lines · Johannes Berg

net/wireless/nl80211.c static int nl80211_set_key(struct sk_buf · line 609

Quoted 8 lines
net/wireless/nl80211.c +3 -2
@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_buf
-	if (key_idx > 3)
+	if (key_idx > 5)
 		return -EINVAL;
 
-	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT])
+	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT] &&
+	    !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT])

I think this should probably check the key index depending on the type, i.e. only permit 4 and 5 for mgmt and 0-3 for data keys.

Yes, I started doing that, but did not cover all places yet. It's somewhat unclear to me where this type of validation should live, i.e., what piece of code should know that key indexes 4 and 5 are used for IGTK at this point taken into account that the index could actually be 0..65535.. Anyway, it may be safer to do it here than to trust on other places being able to handle odd indexes for data frame TX key index.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#14 lore raw

Re: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)

Quoted 14 lines · Jouni Malinen
Quoted 11 lines · Johannes Berg

net/wireless/nl80211.c static int nl80211_set_key(struct sk_buf · line 609

Quoted 8 lines
net/wireless/nl80211.c +3 -2
@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_buf
-	if (key_idx > 3)
+	if (key_idx > 5)
 		return -EINVAL;
 
-	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT])
+	if (!info->attrs[NL80211_ATTR_KEY_DEFAULT] &&
+	    !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT])

I think this should probably check the key index depending on the type, i.e. only permit 4 and 5 for mgmt and 0-3 for data keys.

Quoted 6 lines

Yes, I started doing that, but did not cover all places yet. It's somewhat unclear to me where this type of validation should live, i.e., what piece of code should know that key indexes 4 and 5 are used for IGTK at this point taken into account that the index could actually be 0..65535.. Anyway, it may be safer to do it here than to trust on other places being able to handle odd indexes for data frame TX key index.

I tend to think cfg80211 should do it since I don't see a reasonable use for it when the specs/drafts don't specify anything else. I think this is part of the mistake WEXT made with requiring the drivers to check the input sanity everywhere and duplicating that code into all drivers etc.

johannes

maintainer
#15 lore raw

Re: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)

In reply to Jouni Malinen

One more thing:

Quoted 4 lines
net/mac80211/rx.c +4 -0
+/* Get the BIP key index from MMIE; return -1 if this is not a BIP frame */
+static int ieee80211_get_mmie_keyidx(struct sk_buff *skb)
+{
+	struct ieee80211_mgmt *hdr = (struct ieee80211_mgmt *) skb->data;

net/mac80211/rx.c ieee80211_rx_h_check(struct ieee80211_rx · line 538

Quoted 10 lines
net/mac80211/rx.c +10 -0
+	struct ieee80211_mmie *mmie;
+
+	if (skb->len < 24 + sizeof(*mmie) ||
+	    !is_multicast_ether_addr(hdr->da))
+		return -1;
+
+	if (!ieee80211_is_disassoc(hdr->frame_control) &&
+	    !ieee80211_is_deauth(hdr->frame_control) &&
+	    !ieee80211_is_action(hdr->frame_control))
+		return -1; /* not a robust management frame */

If you reorder the code a bit, you can use the helper below here as well.

net/mac80211/rx.c ieee80211_802_1x_port_control(struct iee · line 1140

Quoted 6 lines
net/mac80211/rx.c +6 -0
+static int ieee80211_is_robust_mgmt_frame(__le16 fc)
+{
+	return ieee80211_is_disassoc(fc) ||
+		ieee80211_is_deauth(fc) ||
+		ieee80211_is_action(fc);
+}

johannes

#16 lore raw

RFC PATCH 5/7 802.11w: WEXT parameter for setting mgmt cipher

In reply to Jouni Malinen

Add a new IW_AUTH parameter for setting cipher suite for multicast/broadcast management frames. This is for full-mac drivers that take care of RSN IE generation for (re)association request frames.

include/linux/wireless.h +4 -1
Index: wireless-testing/include/linux/wireless.h
===================================================================
@@ -577,18 +577,21 @@
 #define IW_AUTH_RX_UNENCRYPTED_EAPOL	8
 #define IW_AUTH_ROAMING_CONTROL		9
 #define IW_AUTH_PRIVACY_INVOKED		10
+#define IW_AUTH_CIPHER_GROUP_MGMT	11
 
 /* IW_AUTH_WPA_VERSION values (bit field) */
 #define IW_AUTH_WPA_VERSION_DISABLED	0x00000001
 #define IW_AUTH_WPA_VERSION_WPA		0x00000002
 #define IW_AUTH_WPA_VERSION_WPA2	0x00000004
 
-/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */
+/* IW_AUTH_PAIRWISE_CIPHER, IW_AUTH_GROUP_CIPHER, and IW_AUTH_CIPHER_GROUP_MGMT
+ * values (bit field) */
 #define IW_AUTH_CIPHER_NONE	0x00000001
 #define IW_AUTH_CIPHER_WEP40	0x00000002
 #define IW_AUTH_CIPHER_TKIP	0x00000004
 #define IW_AUTH_CIPHER_CCMP	0x00000008
 #define IW_AUTH_CIPHER_WEP104	0x00000010
+#define IW_AUTH_CIPHER_AES_CMAC	0x00000020
 
 /* IW_AUTH_KEY_MGMT values (bit field) */
 #define IW_AUTH_KEY_MGMT_802_1X	1
net/mac80211/wext.c +1 -0
Index: wireless-testing/net/mac80211/wext.c
===================================================================
@@ -966,6 +966,7 @@ static int ieee80211_ioctl_siwauth(struc
 	case IW_AUTH_WPA_ENABLED:
 	case IW_AUTH_RX_UNENCRYPTED_EAPOL:
 	case IW_AUTH_KEY_MGMT:
+	case IW_AUTH_CIPHER_GROUP_MGMT:
 		break;
 	case IW_AUTH_DROP_UNENCRYPTED:
 		sdata->drop_unencrypted = !!data->value;

--

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#17 lore raw

RFC PATCH 6/7 802.11w: WEXT configuration for IGTK

In reply to Jouni Malinen

Added new SIOCSIWENCODEEXT algorithm for configuring BIP (AES-CMAC) keys (IGTK).

include/linux/wireless.h +1 -0
Index: wireless-testing/include/linux/wireless.h
===================================================================
@@ -615,6 +615,7 @@
 #define IW_ENCODE_ALG_TKIP	2
 #define IW_ENCODE_ALG_CCMP	3
 #define IW_ENCODE_ALG_PMK	4
+#define IW_ENCODE_ALG_AES_CMAC	5
 /* struct iw_encode_ext ->ext_flags */
 #define IW_ENCODE_EXT_TX_SEQ_VALID	0x00000001
 #define IW_ENCODE_EXT_RX_SEQ_VALID	0x00000002
net/mac80211/wext.c +48 -14

87 lines not on this page · raw message

--

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#18 lore raw

RFC PATCH 7/7 802.11w: Configuration of MFP disabled/optional/required

In reply to Jouni Malinen

Add new WEXT IW_AUTH_* parameter for setting MFP
disabled/optional/required.

include/linux/wireless.h +6 -0
Index: wireless-testing/include/linux/wireless.h
===================================================================
@@ -578,6 +578,7 @@
 #define IW_AUTH_ROAMING_CONTROL		9
 #define IW_AUTH_PRIVACY_INVOKED		10
 #define IW_AUTH_CIPHER_GROUP_MGMT	11
+#define IW_AUTH_MFP			12
 
 /* IW_AUTH_WPA_VERSION values (bit field) */
 #define IW_AUTH_WPA_VERSION_DISABLED	0x00000001
@@ -607,6 +608,11 @@
 #define IW_AUTH_ROAMING_DISABLE	1	/* user space program used for roaming
 					 * control */
 
+/* IW_AUTH_MFP (management frame protection) values */
+#define IW_AUTH_MFP_DISABLED	0	/* MFP disabled */
+#define IW_AUTH_MFP_OPTIONAL	1	/* MFP optional */
+#define IW_AUTH_MFP_REQUIRED	2	/* MFP required */
+
 /* SIOCSIWENCODEEXT definitions */
 #define IW_ENCODE_SEQ_MAX_SIZE	8
 /* struct iw_encode_ext ->alg */
net/mac80211/ieee80211_i.h +5 -0
Index: wireless-testing/net/mac80211/ieee80211_i.h
===================================================================
@@ -372,6 +372,11 @@ struct ieee80211_if_sta {
 	int auth_alg; /* currently used IEEE 802.11 authentication algorithm */
 	int auth_transaction;
 
+#define IEEE80211_MFP_DISABLED 0
+#define IEEE80211_MFP_OPTIONAL 1
+#define IEEE80211_MFP_REQUIRED 2
+	int mfp; /* management frame protection */
+
 	unsigned long ibss_join_req;
 	struct sk_buff *probe_resp; /* ProbeResp template for IBSS */
 	u32 supp_rates_bits[IEEE80211_NUM_BANDS];
net/mac80211/wext.c +7 -0
Index: wireless-testing/net/mac80211/wext.c
===================================================================
@@ -1003,6 +1003,13 @@ static int ieee80211_ioctl_siwauth(struc
 		else
 			ret = -EOPNOTSUPP;
 		break;
+	case IW_AUTH_MFP:
+		if (sdata->vif.type == IEEE80211_IF_TYPE_STA ||
+		    sdata->vif.type == IEEE80211_IF_TYPE_IBSS)
+			sdata->u.sta.mfp = data->value;
+		else
+			ret = -EOPNOTSUPP;
+		break;
 	default:
 		ret = -EOPNOTSUPP;
 		break;

--

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#19 lore raw

Re: [RFC PATCH 7/7] 802.11w: Configuration of MFP disabled/optional/required

net/mac80211/ieee80211_i.h struct ieee80211_if_sta { · line 378

Quoted 5 lines
net/mac80211/ieee80211_i.h +4 -0
+#define IEEE80211_MFP_DISABLED 0
+#define IEEE80211_MFP_OPTIONAL 1
+#define IEEE80211_MFP_REQUIRED 2
+	int mfp; /* management frame protection */

Maybe an enum would be good?

net/mac80211/wext.c static int ieee80211_ioctl_siwauth(struc · line 1009

Quoted 10 lines
net/mac80211/wext.c +4 -0
@@ -1003,6 +1003,13 @@ static int ieee80211_ioctl_siwauth(struc
 		else
 			ret = -EOPNOTSUPP;
 		break;
+	case IW_AUTH_MFP:
+		if (sdata->vif.type == IEEE80211_IF_TYPE_STA ||
+		    sdata->vif.type == IEEE80211_IF_TYPE_IBSS)
+			sdata->u.sta.mfp = data->value;

and shouldn't that be used somewhere?

johannes

#20 lore raw

Re: [RFC PATCH 7/7] 802.11w: Configuration of MFP disabled/optional/required

Quoted 6 lines · Johannes Berg

net/mac80211/ieee80211_i.h struct ieee80211_if_sta { · line 378

Quoted 4 lines
net/mac80211/ieee80211_i.h +4 -0
+#define IEEE80211_MFP_DISABLED 0
+#define IEEE80211_MFP_OPTIONAL 1
+#define IEEE80211_MFP_REQUIRED 2
+	int mfp; /* management frame protection */

Maybe an enum would be good?

Sure.

Quoted 8 lines

net/mac80211/wext.c static int ieee80211_ioctl_siwauth(struc · line 1009

Quoted 6 lines
net/mac80211/wext.c +4 -0
+	case IW_AUTH_MFP:
+		if (sdata->vif.type == IEEE80211_IF_TYPE_STA ||
+		    sdata->vif.type == IEEE80211_IF_TYPE_IBSS)
+			sdata->u.sta.mfp = data->value;

and shouldn't that be used somewhere?

Well, yes. This is still somewhat unclear area to me and in particular, I'm not sure whether the IW_AUTH_MFP parameter will end up being used in mac80211. It would be used if the kernel code (or firmware in fullmac designs) would select the AP. mac80211 may need another configuration item to set whether MFP was actually negotiated during association. This has changed a bit in the latest 802.11w draft and I haven't yet updated my implementation to use the new mechanism. For the time being, sdata->u.sta.mfp is more or less a placeholder for something that may disappear or change to something else..

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#21 lore raw

Re: [RFC PATCH 7/7] 802.11w: Configuration of MFP disabled/optional/required

Quoted 10 lines
Quoted 9 lines

net/mac80211/wext.c static int ieee80211_ioctl_siwauth(struc · line 1009

Quoted 7 lines
net/mac80211/wext.c +4 -0
+	case IW_AUTH_MFP:
+		if (sdata->vif.type == IEEE80211_IF_TYPE_STA ||
+		    sdata->vif.type == IEEE80211_IF_TYPE_IBSS)
+			sdata->u.sta.mfp = data->value;

and shouldn't that be used somewhere?

Quoted 9 lines

Well, yes. This is still somewhat unclear area to me and in particular, I'm not sure whether the IW_AUTH_MFP parameter will end up being used in mac80211. It would be used if the kernel code (or firmware in fullmac designs) would select the AP. mac80211 may need another configuration item to set whether MFP was actually negotiated during association. This has changed a bit in the latest 802.11w draft and I haven't yet updated my implementation to use the new mechanism. For the time being, sdata->u.sta.mfp is more or less a placeholder for something that may disappear or change to something else..

Ok, yeah, that explains why I wasn't really able to see how it determined whether MFP was optional/required for a certain association etc.

johannes

maintainer
#22 lore raw
In reply to Jouni Malinen
Quoted 10 lines

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

#23 lore raw
Quoted 8 lines · Johannes Berg
Quoted 4 lines

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..

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#24 lore raw
Quoted 11 lines · On Tuesday 17 June 2008 19:47:49 Jouni Malinen wrote:
Quoted 8 lines · Johannes Berg
Quoted 4 lines

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.

Quoted 7 lines

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.

Signature · 1 line
Greetings Michael.
maintainer
#25 lore raw
Quoted 12 lines · Michael Buesch
Quoted 11 lines · On Tuesday 17 June 2008 19:47:49 Jouni Malinen wrote:
Quoted 8 lines · Johannes Berg
Quoted 4 lines

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.

Quoted 7 lines
Quoted 7 lines

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.

Quoted 2 lines

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

#26 lore raw
In reply to Michael Buesch
Quoted 2 lines · Michael Buesch

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.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#27 lore raw
Quoted 11 lines · On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
Quoted 2 lines · Michael Buesch

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)

Signature · 1 line
Greetings Michael.
maintainer
#28 lore raw
Quoted 13 lines · Michael Buesch
Quoted 11 lines · On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
Quoted 2 lines · Michael Buesch

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.

Quoted 2 lines

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

#29 lore raw
Quoted 14 lines · On Tuesday 17 June 2008 20:31:47 Johannes Berg wrote:
Quoted 13 lines · Michael Buesch
Quoted 11 lines · On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
Quoted 2 lines · Michael Buesch

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.

Quoted 5 lines
Quoted 2 lines

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.

Signature · 1 line
Greetings Michael.
#30 lore raw
In reply to Jouni Malinen
Quoted 4 lines · Jouni Malinen

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.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#31 lore raw
In reply to Jouni Malinen
Quoted 5 lines

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

maintainer
#32 lore raw
Quoted 10 lines · Johannes Berg
Quoted 4 lines

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

#33 lore raw
Quoted 3 lines · Johannes Berg

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.. ;-)

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#34 lore raw

VLAN testing (and mac80211_hwsim test cases in general)

In reply to Johannes Berg
Quoted 3 lines · Johannes Berg

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.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
maintainer
#35 lore raw

Re: VLAN testing (and mac80211_hwsim test cases in general)

Quoted 6 lines · Jouni Malinen
Quoted 3 lines · Johannes Berg

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? :)

Quoted 6 lines

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.

Quoted 9 lines

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

#36 lore raw

Re: VLAN testing (and mac80211_hwsim test cases in general)

Quoted 4 lines · Johannes Berg

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.

Quoted 3 lines

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.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#37 lore raw

Re: VLAN testing (and mac80211_hwsim test cases in general)

Quoted 8 lines · 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 :$.

Quoted 6 lines

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.