[PATCHv3] mac80211: dynamic wep

[PATCHv3] mac80211: dynamic wep

[Volker Braun]

1) Instead of hacking around ieee80211_privacy_mismatch, remove it
completely. It serves no useful purpose.

2) Don't make assumptions about keyidx==0 on unicast keys.

Signed-off-by: Volker Braun <volker.braun@physik.hu-berlin.de>


diff -rup a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
--- a/net/mac80211/ieee80211.c	2007-08-13 17:08:33.000000000 -0400
+++ b/net/mac80211/ieee80211.c	2007-08-14 18:12:06.000000000 -0400
@@ -3488,7 +3488,6 @@ static ieee80211_txrx_result
 ieee80211_rx_h_check(struct ieee80211_txrx_data *rx)
 {
 	struct ieee80211_hdr *hdr;
-	int always_sta_key;
 	hdr = (struct ieee80211_hdr *) rx->skb->data;
 
 	/* Drop duplicate 802.11 retransmissions (IEEE 802.11 Chap. 9.2.9) */
@@ -3556,29 +3555,19 @@ ieee80211_rx_h_check(struct ieee80211_tx
 		return TXRX_QUEUED;
 	}
 
-	if (rx->sdata->type == IEEE80211_IF_TYPE_STA)
-		always_sta_key = 0;
-	else
-		always_sta_key = 1;
-
-	if (rx->sta && rx->sta->key && always_sta_key) {
-		rx->key = rx->sta->key;
-	} else {
-		if (rx->sta && rx->sta->key)
+	if (rx->fc & IEEE80211_FCTL_PROTECTED) {		
+		if (rx->skb->pkt_type == PACKET_HOST && 
+		    rx->sta && rx->sta->key)
 			rx->key = rx->sta->key;
-		else
-			rx->key = rx->sdata->default_key;
-
-		if ((rx->local->hw.flags & IEEE80211_HW_WEP_INCLUDE_IV) &&
-		    rx->fc & IEEE80211_FCTL_PROTECTED) {
+		else { 
 			int keyidx = ieee80211_wep_get_keyidx(rx->skb);
+			if (keyidx < 0 || keyidx >= NUM_DEFAULT_KEYS)
+				return TXRX_DROP;
+		
+			rx->key = rx->sdata->keys[keyidx];
 
-			if (keyidx >= 0 && keyidx < NUM_DEFAULT_KEYS &&
-			    (!rx->sta || !rx->sta->key || keyidx > 0))
-				rx->key = rx->sdata->keys[keyidx];
-
-			if (!rx->key) {
-				if (!rx->u.rx.ra_match)
+			if (unlikely(!rx->key)) {
+				if (!rx->u.rx.ra_match) 
 					return TXRX_DROP;
 				printk(KERN_DEBUG "%s: RX WEP frame with "
 				       "unknown keyidx %d (A1=" MAC_FMT " A2="
@@ -3587,8 +3576,10 @@ ieee80211_rx_h_check(struct ieee80211_tx
 				       MAC_ARG(hdr->addr1),
 				       MAC_ARG(hdr->addr2),
 				       MAC_ARG(hdr->addr3));
-				if (!rx->local->apdev)
+				if (!rx->local->apdev) {
+					rx->local->dot11WEPUndecryptableCount++;
 					return TXRX_DROP;
+				}
 				ieee80211_rx_mgmt(
 					rx->local, rx->skb, rx->u.rx.status,
 					ieee80211_msg_wep_frame_unknown_key);
@@ -3597,7 +3588,7 @@ ieee80211_rx_h_check(struct ieee80211_tx
 		}
 	}
 
-	if (rx->fc & IEEE80211_FCTL_PROTECTED && rx->key && rx->u.rx.ra_match) {
+	if (rx->key && rx->u.rx.ra_match) {
 		rx->key->tx_rx_count++;
 		if (unlikely(rx->local->key_tx_rx_threshold &&
 			     rx->key->tx_rx_count >
diff -rup a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
--- a/net/mac80211/ieee80211_ioctl.c	2007-08-13 17:08:33.000000000 -0400
+++ b/net/mac80211/ieee80211_ioctl.c	2007-08-13 17:12:48.000000000 -0400
@@ -479,13 +479,14 @@ static int ieee80211_set_encryption(stru
 
 	sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 
-	if (is_broadcast_ether_addr(sta_addr)) {
+	if (idx < 0 || idx >= NUM_DEFAULT_KEYS) {
+		printk(KERN_DEBUG "%s: set_encrypt - invalid idx = %d\n",
+		       dev->name, idx);
+		return -EINVAL;
+	}
+
+	if (is_multicast_ether_addr(sta_addr)) {
 		sta = NULL;
-		if (idx >= NUM_DEFAULT_KEYS) {
-			printk(KERN_DEBUG "%s: set_encrypt - invalid idx=%d\n",
-			       dev->name, idx);
-			return -EINVAL;
-		}
 		key = sdata->keys[idx];
 
 		/* TODO: consider adding hwaccel support for these; at least
@@ -499,7 +500,7 @@ static int ieee80211_set_encryption(stru
 		 * being, this can be only set at compile time. */
 	} else {
 		set_tx_key = 0;
-		if (idx != 0) {
+		if (idx != 0 && alg != ALG_WEP) {
 			printk(KERN_DEBUG "%s: set_encrypt - non-zero idx for "
 			       "individual key\n", dev->name);
 			return -EINVAL;
diff -rup a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
--- a/net/mac80211/ieee80211_sta.c	2007-08-13 17:08:33.000000000 -0400
+++ b/net/mac80211/ieee80211_sta.c	2007-08-14 15:35:45.000000000 -0400
@@ -1117,30 +1117,6 @@ void ieee80211_send_dls_teardown(struct 
 }
 
 
-static int ieee80211_privacy_mismatch(struct net_device *dev,
-				      struct ieee80211_if_sta *ifsta)
-{
-	struct ieee80211_sta_bss *bss;
-	int res = 0;
-
-	if (!ifsta || ifsta->mixed_cell ||
-	    ifsta->key_mgmt != IEEE80211_KEY_MGMT_NONE)
-		return 0;
-
-	bss = ieee80211_rx_bss_get(dev, ifsta->bssid);
-	if (!bss)
-		return 0;
-
-	if (ieee80211_sta_wep_configured(dev) !=
-	    !!(bss->capability & WLAN_CAPABILITY_PRIVACY))
-		res = 1;
-
-	ieee80211_rx_bss_put(dev, bss);
-
-	return res;
-}
-
-
 static void ieee80211_associate(struct net_device *dev,
 				struct ieee80211_if_sta *ifsta)
 {
@@ -1156,12 +1132,6 @@ static void ieee80211_associate(struct n
 	ifsta->state = IEEE80211_ASSOCIATE;
 	printk(KERN_DEBUG "%s: associate with AP " MAC_FMT "\n",
 	       dev->name, MAC_ARG(ifsta->bssid));
-	if (ieee80211_privacy_mismatch(dev, ifsta)) {
-		printk(KERN_DEBUG "%s: mismatch in privacy configuration and "
-		       "mixed-cell disabled - abort association\n", dev->name);
-		ifsta->state = IEEE80211_DISABLED;
-		return;
-	}
 
 	ieee80211_send_assoc(dev, ifsta);
 
@@ -3549,14 +3519,6 @@ void ieee80211_sta_work(struct work_stru
 		       ifsta->state);
 		break;
 	}
-
-	if (ieee80211_privacy_mismatch(dev, ifsta)) {
-		printk(KERN_DEBUG "%s: privacy configuration mismatch and "
-		       "mixed-cell disabled - disassociate\n", dev->name);
-
-		ieee80211_send_disassoc(dev, ifsta, WLAN_REASON_UNSPECIFIED);
-		ieee80211_set_disassoc(dev, ifsta, 0);
-	}
 }
 
 

Re: [PATCHv3] mac80211: dynamic wep

[Michael Wu]

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

On Tuesday 14 August 2007 21:12, Volker Braun wrote:
> 2) Don't make assumptions about keyidx==0 on unicast keys.
>
I'm curious.. does decryption still work if unicast keys with keyidx > 0 are 
turned into regular keys? I suspect keyidx > 0 is done to allow hardware 
without individual WEP key support to continue using hardware WEP.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCHv3] mac80211: dynamic wep

[Volker Braun]

On Tue, 2007-08-14 at 23:55 -0700, Michael Wu wrote:
> I suspect keyidx > 0 is done to allow hardware 
> without individual WEP key support to continue using hardware WEP.

I've wondered for a long time why Cisco chose to use keyidx>0 for WEP
unicast keys, but I think I finally understand that this is a weird
feature (8.5.1): In a mixed WEP and TKIP network a WEP key[0] would
conflict with the TKIP key (which must have keyidx == 0), forcing a dumb
TKIP STA to downgrade to WEP. (A good TKIP STA would just rely on
per-STA keys and not have this problem)

Volker Braun

Re: [PATCHv3] mac80211: dynamic wep

[Michael Wu]

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

On Wednesday 15 August 2007 08:24, Volker Braun wrote:
> I've wondered for a long time why Cisco chose to use keyidx>0 for WEP
> unicast keys, but I think I finally understand that this is a weird
> feature (8.5.1): In a mixed WEP and TKIP network a WEP key[0] would
> conflict with the TKIP key (which must have keyidx == 0), forcing a dumb
> TKIP STA to downgrade to WEP. (A good TKIP STA would just rely on
> per-STA keys and not have this problem)
>
Hm.. I'm not really convinced that this is the main reason. Can you check and 
see if the keyidx that wpa_supplicant configures and the keyidx used in 
unicast frames are the same?

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCHv3] mac80211: dynamic wep

[Volker Braun]

On Wed, 2007-08-15 at 21:58 -0700, Michael Wu wrote:
> Hm.. I'm not really convinced that this is the main reason. Can you check and 
> see if the keyidx that wpa_supplicant configures and the keyidx used in 
> unicast frames are the same?

Its true, wpa_supplicant and the unicast frames all have keyidx==3. I
added these printk's:

=============
        if (rx->fc & IEEE80211_FCTL_PROTECTED) {                
                if (rx->skb->pkt_type == PACKET_HOST)
                        printk(KERN_DEBUG "%s: RX WEP unicast frame from "
                               MAC_FMT " with keyidx %d\n",
                               rx->dev->name, MAC_ARG(hdr->addr2),
                               ieee80211_wep_get_keyidx(rx->skb) );

                if (rx->skb->pkt_type == PACKET_HOST && 
                    rx->sta && rx->sta->key) {

                        rx->key = rx->sta->key;
                        printk(KERN_DEBUG "Using STA key\n");
=============

Then I get a debug log that contains a lot of

...
Aug 16 14:03:58 thinkpad kernel: wlan0: RX WEP unicast frame from 00:15:c6:5e:e5:70 with keyidx 3
Aug 16 14:03:58 thinkpad kernel: Using STA key
Aug 16 14:03:58 thinkpad kernel: wlan0: RX WEP unicast frame from 00:15:c6:5e:e5:70 with keyidx 3
Aug 16 14:03:58 thinkpad kernel: Using STA key
Aug 16 14:03:58 thinkpad kernel: wlan0: RX WEP unicast frame from 00:15:c6:5e:e5:70 with keyidx 3
Aug 16 14:03:58 thinkpad kernel: Using STA key
...


Here is the relevant output from wpa_supplicant -Dwext -ddd:

EAPOL: KEY_RX entering state KEY_RECEIVE
EAPOL: processKey
EAPOL: RX IEEE 802.1X ver=1 type=3 len=57 EAPOL-Key: type=1 key_length=13 key_index=0x1
EAPOL: EAPOL-Key key signature verified
EAPOL: Decrypted(RC4) key - hexdump(len=13): [REMOVED]
EAPOL: Setting dynamic WEP key: broadcast keyidx 1 len 13
wpa_driver_wext_set_key: alg=1 key_idx=1 set_tx=0 seq_len=0 key_len=13
RX EAPOL from 00:15:c6:5e:e5:70
RX EAPOL - hexdump(len=48): 01 03 00 2c 01 00 0d 00 00 46 c4 8d 8a 35 ae f9 fc 6e 64 dc 34 71 cf 55 8f 4f 40 46 4e d2 a1 83 4f b5 fa 93 15 93 7b 02 d3 96 a5 cf e6 74 dd 93
EAPOL: Received EAPOL-Key frame
EAPOL: KEY_RX entering state KEY_RECEIVE
EAPOL: processKey
EAPOL: RX IEEE 802.1X ver=1 type=3 len=44 EAPOL-Key: type=1 key_length=13 key_index=0x83
EAPOL: EAPOL-Key key signature verified
EAPOL: using part of EAP keying material data encryption key - hexdump(len=13): [REMOVED]
EAPOL: Setting dynamic WEP key: unicast keyidx 3 len 13
wpa_driver_wext_set_key: alg=1 key_idx=3 set_tx=128 seq_len=0 key_len=13
EAPOL: all required EAPOL-Key frames received
WPA: EAPOL processing complete
Cancelling authentication timeout
State: ASSOCIATED -> COMPLETED
CTRL-EVENT-CONNECTED - Connection to 00:15:c6:5e:e5:70 completed (auth) [id=0 id_str=]

key_index & 0x80 means unicast, and the actual index is 3 = key_index &
0x03.

Re: [PATCHv3] mac80211: dynamic wep

[Johannes Berg]

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

On Thu, 2007-08-16 at 14:26 -0400, Volker Braun wrote:

> key_index & 0x80 means unicast, and the actual index is 3 = key_index &
> 0x03.

So that just means we have to allow bending the rules and allow
configuring a non-zero key index with pairwise WEP keys. Not too much of
a problem, I'd think.

As for the key selection changes on reception, I don't like those you've
made but the code is totally wrong even for WPA.

johannes

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

Re: [PATCHv3] mac80211: dynamic wep

[Johannes Berg]

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

On Wed, 2007-08-15 at 00:12 -0400, Volker Braun wrote:
> 1) Instead of hacking around ieee80211_privacy_mismatch, remove it
> completely. It serves no useful purpose.

The purpose seems to be to avoid associating to BSSes that have privacy
enabled when we don't have any keys nor a tool told us that it's ok.
This again raises the question of why wpa_supplicant doesn't set the
IW_AUTH_KEY_MGMT_802_1X flag that should get you around the mismatch
check.

> @@ -3488,7 +3488,6 @@ static ieee80211_txrx_result
>  ieee80211_rx_h_check(struct ieee80211_txrx_data *rx)
>  {
>  	struct ieee80211_hdr *hdr;
> -	int always_sta_key;
>  	hdr = (struct ieee80211_hdr *) rx->skb->data;
>  
>  	/* Drop duplicate 802.11 retransmissions (IEEE 802.11 Chap. 9.2.9) */
> @@ -3556,29 +3555,19 @@ ieee80211_rx_h_check(struct ieee80211_tx
>  		return TXRX_QUEUED;
>  	}
>  
> -	if (rx->sdata->type == IEEE80211_IF_TYPE_STA)
> -		always_sta_key = 0;
> -	else
> -		always_sta_key = 1;
> -
> -	if (rx->sta && rx->sta->key && always_sta_key) {
> -		rx->key = rx->sta->key;
> -	} else {
> -		if (rx->sta && rx->sta->key)
> +	if (rx->fc & IEEE80211_FCTL_PROTECTED) {		
> +		if (rx->skb->pkt_type == PACKET_HOST && 
> +		    rx->sta && rx->sta->key)
>  			rx->key = rx->sta->key;
> -		else
> -			rx->key = rx->sdata->default_key;
> -
> -		if ((rx->local->hw.flags & IEEE80211_HW_WEP_INCLUDE_IV) &&
> -		    rx->fc & IEEE80211_FCTL_PROTECTED) {
> +		else { 
>  			int keyidx = ieee80211_wep_get_keyidx(rx->skb);
> +			if (keyidx < 0 || keyidx >= NUM_DEFAULT_KEYS)
> +				return TXRX_DROP;
> +		
> +			rx->key = rx->sdata->keys[keyidx];
>  
> -			if (keyidx >= 0 && keyidx < NUM_DEFAULT_KEYS &&
> -			    (!rx->sta || !rx->sta->key || keyidx > 0))
> -				rx->key = rx->sdata->keys[keyidx];
> -
> -			if (!rx->key) {
> -				if (!rx->u.rx.ra_match)
> +			if (unlikely(!rx->key)) {
> +				if (!rx->u.rx.ra_match) 
>  					return TXRX_DROP;
>  				printk(KERN_DEBUG "%s: RX WEP frame with "
>  				       "unknown keyidx %d (A1=" MAC_FMT " A2="
> @@ -3587,8 +3576,10 @@ ieee80211_rx_h_check(struct ieee80211_tx
>  				       MAC_ARG(hdr->addr1),
>  				       MAC_ARG(hdr->addr2),
>  				       MAC_ARG(hdr->addr3));
> -				if (!rx->local->apdev)
> +				if (!rx->local->apdev) {
> +					rx->local->dot11WEPUndecryptableCount++;
>  					return TXRX_DROP;
> +				}
>  				ieee80211_rx_mgmt(
>  					rx->local, rx->skb, rx->u.rx.status,
>  					ieee80211_msg_wep_frame_unknown_key);

All those key selection changes and the VLAN group key thing have me
wondering now. Also see Larry's mail (meaningless messages), these
things are related.

> @@ -3597,7 +3588,7 @@ ieee80211_rx_h_check(struct ieee80211_tx
>  		}
>  	}
>  
> -	if (rx->fc & IEEE80211_FCTL_PROTECTED && rx->key && rx->u.rx.ra_match) {
> +	if (rx->key && rx->u.rx.ra_match) {

That's just an optimisation, right? (If we have a key, the frame was
encrypted)
 
> -	if (is_broadcast_ether_addr(sta_addr)) {
> +	if (idx < 0 || idx >= NUM_DEFAULT_KEYS) {
> +		printk(KERN_DEBUG "%s: set_encrypt - invalid idx = %d\n",
> +		       dev->name, idx);
> +		return -EINVAL;
> +	}
> +
> +	if (is_multicast_ether_addr(sta_addr)) {

I still haven't understood why you changed from broadcast to multicast
here. Nor why you moved the key index check outside the check, if it's a
not a group key then the key index is irrelevant.

>  		set_tx_key = 0;
> -		if (idx != 0) {
> +		if (idx != 0 && alg != ALG_WEP) {
>  			printk(KERN_DEBUG "%s: set_encrypt - non-zero idx for "
>  			       "individual key\n", dev->name);
>  			return -EINVAL;

So wpa_supplicant is actually trying to set a pairwise key with a key
index that isn't zero? That's really weird and definitely against the
rules. Is that somehow required? Shouldn't the AP be able to live with
you setting the key index to zero? Could you try that by forcing the
index to zero in this case?

Actually, maybe this is some weird Cisco rule-bending as you said, but
then I'd rather suspect that it's because of interaction with pre-shared
WEP keys rather than TKIP. In any case, it seems acceptable to remove
this restriction even if we then violate the standard.

johannes

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

Re: [PATCHv3] mac80211: dynamic wep

[Johannes Berg]

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

On Fri, 2007-08-17 at 01:50 +0200, Johannes Berg wrote:
> On Wed, 2007-08-15 at 00:12 -0400, Volker Braun wrote:
> > 1) Instead of hacking around ieee80211_privacy_mismatch, remove it
> > completely. It serves no useful purpose.
> 
> The purpose seems to be to avoid associating to BSSes that have privacy
> enabled when we don't have any keys nor a tool told us that it's ok.
> This again raises the question of why wpa_supplicant doesn't set the
> IW_AUTH_KEY_MGMT_802_1X flag that should get you around the mismatch
> check.

In any case, I don't mind removing it, but if you do it please also
remove the stuff related to it from ioctl.c and the key_mgmt variable.

johannes

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

Re: [PATCHv3] mac80211: dynamic wep

[Volker Braun]

On Fri, 2007-08-17 at 01:50 +0200, Johannes Berg wrote:
> On Wed, 2007-08-15 at 00:12 -0400, Volker Braun wrote:
> > 1) Instead of hacking around ieee80211_privacy_mismatch, remove it
> > completely. It serves no useful purpose.
> The purpose seems to be to avoid associating to BSSes that have privacy
> enabled when we don't have any keys nor a tool told us that it's ok

NetworkManager can do that for you, no need to duplicate that in the
driver where you can't give any useful feedback to the user. Maybe you
want to test whether your AP _really_ discards unencrypted data? 

> > -	if (rx->fc & IEEE80211_FCTL_PROTECTED && rx->key && rx->u.rx.ra_match) {
> > +	if (rx->key && rx->u.rx.ra_match) {
> 
> That's just an optimisation, right? (If we have a key, the frame was
> encrypted)

Yes.

> > -	if (is_broadcast_ether_addr(sta_addr)) {
> > +	if (idx < 0 || idx >= NUM_DEFAULT_KEYS) {
> > +		printk(KERN_DEBUG "%s: set_encrypt - invalid idx = %d\n",
> > +		       dev->name, idx);
> > +		return -EINVAL;
> > +	}
> > +
> > +	if (is_multicast_ether_addr(sta_addr)) {
> 
> I still haven't understood why you changed from broadcast to multicast
> here. Nor why you moved the key index check outside the check, if it's a
> not a group key then the key index is irrelevant.

It should be broadcast, you are right.

The key index is saved later on in key->keyidx. So I wanted to be on the
safe side and make sure that a legal value is stored there.

> So wpa_supplicant is actually trying to set a pairwise key with a key
> index that isn't zero? That's really weird and definitely against the
> rules. Is that somehow required? Shouldn't the AP be able to live with
> you setting the key index to zero? Could you try that by forcing the
> index to zero in this case?
> 
> Actually, maybe this is some weird Cisco rule-bending as you said, but
> then I'd rather suspect that it's because of interaction with pre-shared
> WEP keys rather than TKIP. In any case, it seems acceptable to remove
> this restriction even if we then violate the standard.

First of all, we violate the standard by looking at the keyindex in case
of a pairwise key. Now granted, Cisco also violates it, but in a way
that is never visible to standards-compliant STAs. We must set the
keyindex to zero on outgoing pairwise key-encrypted data, but that is
kind of irrelevant since the AP is forced to ignore that key index on
receive.

Re: [PATCHv3] mac80211: dynamic wep

[Johannes Berg]

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

On Fri, 2007-08-17 at 10:16 -0400, Volker Braun wrote:

> NetworkManager can do that for you, no need to duplicate that in the
> driver where you can't give any useful feedback to the user. Maybe you
> want to test whether your AP _really_ discards unencrypted data? 

Can't really do that since it'll ack the packet anyway :)

> It should be broadcast, you are right.

Don't think it matters much, was just curious.

> The key index is saved later on in key->keyidx. So I wanted to be on the
> safe side and make sure that a legal value is stored there.

Right. I was totally confused about some things and just reread the
standard again :)

> First of all, we violate the standard by looking at the keyindex in case
> of a pairwise key.

I don't think we do look at it, do we? In any case, if it was there I
removed it with the RFC key selection patch.

> Now granted, Cisco also violates it, but in a way
> that is never visible to standards-compliant STAs. We must set the
> keyindex to zero on outgoing pairwise key-encrypted data, but that is
> kind of irrelevant since the AP is forced to ignore that key index on
> receive.

But then I don't understand why we try to set a non-zero key index for
the key.

johannes

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

Re: [PATCHv3] mac80211: dynamic wep

[Jouni Malinen]

On Fri, Aug 17, 2007 at 05:09:05PM +0200, Johannes Berg wrote:
> On Fri, 2007-08-17 at 10:16 -0400, Volker Braun wrote:
> > Now granted, Cisco also violates it, but in a way
> > that is never visible to standards-compliant STAs. We must set the
> > keyindex to zero on outgoing pairwise key-encrypted data, but that is
> > kind of irrelevant since the AP is forced to ignore that key index on
> > receive.
> 
> But then I don't understand why we try to set a non-zero key index for
> the key.

If I remember correctly, Cisco APs in IEEE 802.1X/dynamic WEP
configuration rotate between key indexes 0 and 1 for broadcast/multicast
keys and indexes 2 and 3 for unicast. In standard IEEE 802.1X, doing
rekeying for broadcast keys by using two key indexes can be used to
allow the change to happen without any packets being lost (send the new
key first to all clients and only after that start using the new key).

I would assume that Cisco is trying to do the same kind of smooth
rekeying for unicast here (not that I have verified that this is the
case, but that sounds semi-logical). Consequently, we would actually
need to configure two pairwise keys at the same time and not only set
the non-zero key index but to actually use these keys when decrypting
frames.. My guess would be that this is expected to work by using
broadcast WEP keys instead of unicast keymapping keys, but it is
somewhat broken design. Anyway, that is what has been deployed in number
of networks. Eventually, this will hopefully go away once the networks
are updated to WPA/WPA2, but some organizations take long time to change
this kind of things..

wpa_supplicant is just blindly following what the AP tells it to when
setting keys (EAPOL-Key frames include the key index). Consequently, the
driver/mac80211 ends up being told to use this non-zero key indexes for
unicast keys.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCHv3] mac80211: dynamic wep

[Volker Braun]

The APs rotate key index 1 and 2 for broadcast keys as you said, but
I've never seen it use anything but key index 3 for unicast keys. Key
index 0 is apparently never used. 

I understand that rekeying broadcast keys while all STA's exchange
broadcast traffic has a synchronization problem. But for unicast traffic
there is no way to lose packets during rekeying since at any given time
only one packet can be in the air. Am I missing something?

Re: [PATCHv3] mac80211: dynamic wep

[dragoran]

Whats the status of this patch?
I tested iwl3945 with dynamic wep and it fails to acciotate. ipw3945 works.

Re: [PATCHv3] mac80211: dynamic wep

[Johannes Berg]

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

On Wed, 2007-09-05 at 16:05 +0200, dragoran wrote:
> Whats the status of this patch?

You'd really make life easier if you could post emails with a valid
References header so they'd be sorted into the right thread.... Please
check if your mail client can do that.

I'm handling the patch in question. Patience.

johannes

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

Re: [PATCHv3] mac80211: dynamic wep

[dragoran]

Johannes Berg wrote:
> On Wed, 2007-09-05 at 16:05 +0200, dragoran wrote:
>   
>> Whats the status of this patch?
>>     
>
> You'd really make life easier if you could post emails with a valid
> References header so they'd be sorted into the right thread.... Please
> check if your mail client can do that.
>
>   
sorry the mails where not in my inbox anymore so I had to copy & paste 
the subject line to respond.
should not happen in the future.
> I'm handling the patch in question. Patience.
>
>   
ok thx