Thread: [Madwifi-devel] More on MADWifi & Xsupplicant
Status: Beta
Brought to you by:
otaku
From: Terry S. <gal...@ma...> - 2004-06-24 06:25:40
Attachments:
madwifi_key_patch-5-12-2004.patch
|
Alright... here we go again. ;-) Sorry for the flip flopping... It seems that my first assertion was correct. MADWifi *IS* changing the broadcast key to the transmit key, which is why I am having problems. Any AP out there that sends the broadcast key *after* the unicast key will likely suffer from this problem. Here's the proof: I put some debug code into xsupplicant to call "iwlist ath0 key" whenever a key was set, so I could see what was going on key-by-key. First, I reset the first two key slots to 0, to be sure things started fresh. Note that my transmit key is slot 1 to start: ath0 3 key sizes : 40, 104, 128bits 4 keys available : [1]: 0000-0000-0000-0000-0000-0000-00 (104 bits) [2]: 0000-0000-0000-0000-0000-0000-00 (104 bits) [3]: off [4]: off Current Transmit Key: [1] Security mode:open Next, I authenticated, and got my first broadcast key: [STATE] (global) -> AUTHENTICATED Processing EAPoL-Key! keying length = 32 [INT] Key Descriptor = 1 [INT] Key Length = 13 [INT] Replay Counter = 83 AA 98 65 00 01 02 F6 [INT] Key IV = 52 4E 31 80 7A 79 DF 68 66 07 6E 09 2F DE B2 64 [INT] Key Index (RAW) = 01 [INT] Key Signature = 89 88 1B F2 11 23 A2 72 0E 7B EF 09 C5 05 47 8C [INT] EAPoL Key Processed: broadcast [2] 13 bytes. [INT] Key before decryption : 3B 4C EC 7F 0E 72 24 83 DA 38 E0 24 EF [INT] Key after decryption : 92 AB E3 2A 07 B0 16 B7 DA 56 C4 58 F4 [INT] Successfully set WEP key [2] ath0 3 key sizes : 40, 104, 128bits 4 keys available : [1]: 0000-0000-0000-0000-0000-0000-00 (104 bits) [2]: 92AB-E32A-07B0-16B7-DA56-C458-F4 (104 bits) [3]: off [4]: off Current Transmit Key: [2] Security mode:open Ok, the first thing I would like to point out here, is that the driver set key slot 2 as my transmit key, which it should *NOT* have done. (We're sending proper key-length 0 keys to set the index, and we don't do this for broadcast keys...) Next, the transmit key is received: Processing EAPoL-Key! keying length = 32 [INT] Key Descriptor = 1 [INT] Key Length = 13 [INT] Replay Counter = 83 AA 98 65 00 01 02 F7 [INT] Key IV = 00 97 7C CA 85 6A 52 21 47 6F 6F 1C 70 A2 81 A8 [INT] Key Index (RAW) = 80 [INT] Key Signature = CB BE FA 27 C7 74 43 13 8D 95 59 3C 61 9A D7 16 [INT] EAPoL Key Processed: unicast [1] 13 bytes. [INT] Key before decryption : 0B FF C2 16 28 EA 45 0A 7B B9 F1 F9 3F [INT] Key after decryption : 48 7F FB E7 3D 7C E1 4F 5A 31 BD 8D D6 [INT] Successfully set WEP key [1] [INT] Successfully set the WEP transmit key [1] ath0 3 key sizes : 40, 104, 128bits 4 keys available : [1]: 487F-FBE7-3D7C-E14F-5A31-BD8D-D6 (104 bits) [2]: 92AB-E32A-07B0-16B7-DA56-C458-F4 (104 bits) [3]: off [4]: off Current Transmit Key: [1] Security mode:open Ok, notice that the key was set, and made the transmit key by xsupplicant: "[INT] Successfully set the WEP transmit key [1]". At this point, I can pass traffic. I have been able to successfully test this case over and over again, I can always send traffic for a split second after authentication, until I get the next key: Processing EAPoL-Key! keying length = 32 [INT] Key Descriptor = 1 [INT] Key Length = 13 [INT] Replay Counter = 83 AA 98 67 00 01 03 0D [INT] Key IV = 27 D8 2B 15 44 9B BE A0 22 19 14 3E DF EB 05 04 [INT] Key Index (RAW) = 01 [INT] Key Signature = F8 DA 6A 5D 93 01 79 8D D0 8E DA 4A AC A3 1E 45 [INT] EAPoL Key Processed: broadcast [2] 13 bytes. [INT] Key before decryption : F6 09 7A C1 06 1F 33 77 9E A5 93 B2 2C [INT] Key after decryption : 92 AB E3 2A 07 B0 16 B7 DA 56 C4 58 F4 [INT] Successfully set WEP key [2] ath0 3 key sizes : 40, 104, 128bits 4 keys available : [1]: 487F-FBE7-3D7C-E14F-5A31-BD8D-D6 (104 bits) [2]: 92AB-E32A-07B0-16B7-DA56-C458-F4 (104 bits) [3]: off [4]: off Current Transmit Key: [2] Security mode:open Notice above that we are NOT setting the transmit index here as we did with the unicast key, but the driver sets the transmit index to 2 anyway. At this point traffic no longer flows *correctly* because the driver is using the wrong transmit key. Ok, now I'm going to jump over to the HEAD branch patch that was submitted by Paul Stewart of Xerox PARC, because I think I can explain that patch now that I understand more completely what is going on. First change: int kid, error, wepchange = 0, zerokey = 0, i; "zerokey" was added, and wepchange and zerokey were initialized to 0: Second Change: for (i = 0; i < erq->length && keybuf[i] == 0; i++); zerokey = (i == erq->length); I'm not exactly sure what's going on here, other than zerokey is being set to true (1) if the key should be set as the txkey (that is, if the key is 0 length): Third Change: And finally, if the key length is zero, we need to set this key as the txkey, because we *only* want to set the txkey when a zero-length key is set with the wireless API (as per the man page for iwconfig): if (zerokey) { ic->ic_wep_txkey = kid; wepchange = (ic->ic_flags & IEEE80211_F_WEPON) == 0; ic->ic_flags |= IEEE80211_F_WEPON; } And here is the man page excerpt: key/enc[ryption] Used to manipulate encryption or scrambling keys and security mode. To set the current encryption key, just enter the key in hex digits as XXXX-XXXX-XXXX-XXXX or XXXXXXXX. To set a key other than the current key, prepend or append [index] to the key itself (this won't change which is the active key). You can also enter the key as an ASCII string by using the s: prefix. Passphrase is currently not supported. To change which key is the current active key, just enter [index] (without entering any key value). Xsupplicant is basically doing something like "iwconfig ath0 key [1]" internally to set the transmit key (where [1] is the index sent in the key message from the AP). Unfortunately, the MADWifi driver, in its current incarnation without the above patched pieces, is setting every new key as the transmit key, which is incorrect from an 802.1X standpoint, since only unicast key messages should be interpreted and set as the transmit key. (Other Linux drivers "behave correctly" in this regard). So, Paul's patch fixes this problem in HEAD. A different patch will be needed for WPA branch, since the code base is different... but hopefully this helps clarify things. And for completeness, here is Paul's patch once again. Does that help, Sam? Thanks! - Terry |
From: Nick P. <npe...@cs...> - 2004-06-25 02:37:45
Attachments:
npetroni_wpa_iwconfig.patch
|
All, Attached you will find a simple patch that I believe will solve the issues described by Terry when using Xsupplicant. I will describe the problem and the solution briefly. The attached patch is for the WPA branch and modifies only a single conditional. Problem: The semantics for SIWENCODE are wrong. Setting WEP material for a key should not necessarily change the TX key to that key number. The exception to this rule is when WEP is currently off, in which case setting a key should turn it on and set the current key to that key. When WEP is on, the only way to set the TX key should be a 0 length call for that key. Solution: Change the function that handles SIWENCODE such that it only changes the TX key under two conditions (assuming the rest of the call is correct). First, if the key length is 0 (erq->length == 0). Second, if WEP is off (!(ic->ic_flags & IEEE80211_F_PRIVACY)) As for this issue of setting 0 keys, I do not currently believe this is necessary. I am able to force an open authentication just by setting a false key, no matter what that key is. Comments welcome. Thanks, nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Thu, 24 Jun 2004, Terry Simons wrote: > Alright... here we go again. ;-) > > Sorry for the flip flopping... > > It seems that my first assertion was correct. MADWifi *IS* changing > the broadcast key to the transmit key, which is why I am having > problems. > > Any AP out there that sends the broadcast key *after* the unicast key > will likely suffer from this problem. > > Here's the proof: > > I put some debug code into xsupplicant to call "iwlist ath0 key" > whenever a key was set, so I could see what was going on key-by-key. > > First, I reset the first two key slots to 0, to be sure things started > fresh. Note that my transmit key is slot 1 to start: > > ath0 3 key sizes : 40, 104, 128bits > 4 keys available : > [1]: 0000-0000-0000-0000-0000-0000-00 (104 bits) > [2]: 0000-0000-0000-0000-0000-0000-00 (104 bits) > [3]: off > [4]: off > Current Transmit Key: [1] > Security mode:open > > Next, I authenticated, and got my first broadcast key: > > [STATE] (global) -> AUTHENTICATED > Processing EAPoL-Key! > keying length = 32 > [INT] Key Descriptor = 1 > [INT] Key Length = 13 > [INT] Replay Counter = 83 AA 98 65 00 01 02 F6 > [INT] Key IV = 52 4E 31 80 7A 79 DF 68 66 07 6E 09 2F DE B2 64 > [INT] Key Index (RAW) = 01 > [INT] Key Signature = 89 88 1B F2 11 23 A2 72 0E 7B EF 09 C5 05 47 8C > [INT] EAPoL Key Processed: broadcast [2] 13 bytes. > [INT] Key before decryption : 3B 4C EC 7F 0E 72 24 83 DA 38 E0 24 EF > [INT] Key after decryption : 92 AB E3 2A 07 B0 16 B7 DA 56 C4 58 F4 > [INT] Successfully set WEP key [2] > ath0 3 key sizes : 40, 104, 128bits > 4 keys available : > [1]: 0000-0000-0000-0000-0000-0000-00 (104 bits) > [2]: 92AB-E32A-07B0-16B7-DA56-C458-F4 (104 bits) > [3]: off > [4]: off > Current Transmit Key: [2] > Security mode:open > > Ok, the first thing I would like to point out here, is that the driver > set key slot 2 as my transmit key, which it should *NOT* have done. > (We're sending proper key-length 0 keys to set the index, and we don't > do this for broadcast keys...) > > Next, the transmit key is received: > > Processing EAPoL-Key! > keying length = 32 > [INT] Key Descriptor = 1 > [INT] Key Length = 13 > [INT] Replay Counter = 83 AA 98 65 00 01 02 F7 > [INT] Key IV = 00 97 7C CA 85 6A 52 21 47 6F 6F 1C 70 A2 81 A8 > [INT] Key Index (RAW) = 80 > [INT] Key Signature = CB BE FA 27 C7 74 43 13 8D 95 59 3C 61 9A D7 16 > [INT] EAPoL Key Processed: unicast [1] 13 bytes. > [INT] Key before decryption : 0B FF C2 16 28 EA 45 0A 7B B9 F1 F9 3F > [INT] Key after decryption : 48 7F FB E7 3D 7C E1 4F 5A 31 BD 8D D6 > [INT] Successfully set WEP key [1] > [INT] Successfully set the WEP transmit key [1] > ath0 3 key sizes : 40, 104, 128bits > 4 keys available : > [1]: 487F-FBE7-3D7C-E14F-5A31-BD8D-D6 (104 bits) > [2]: 92AB-E32A-07B0-16B7-DA56-C458-F4 (104 bits) > [3]: off > [4]: off > Current Transmit Key: [1] > Security mode:open > > Ok, notice that the key was set, and made the transmit key by > xsupplicant: "[INT] Successfully set the WEP transmit key [1]". > > At this point, I can pass traffic. I have been able to successfully > test this case over and over again, I can always send traffic for a > split second after authentication, until I get the next key: > > Processing EAPoL-Key! > keying length = 32 > [INT] Key Descriptor = 1 > [INT] Key Length = 13 > [INT] Replay Counter = 83 AA 98 67 00 01 03 0D > [INT] Key IV = 27 D8 2B 15 44 9B BE A0 22 19 14 3E DF EB 05 04 > [INT] Key Index (RAW) = 01 > [INT] Key Signature = F8 DA 6A 5D 93 01 79 8D D0 8E DA 4A AC A3 1E 45 > [INT] EAPoL Key Processed: broadcast [2] 13 bytes. > [INT] Key before decryption : F6 09 7A C1 06 1F 33 77 9E A5 93 B2 2C > [INT] Key after decryption : 92 AB E3 2A 07 B0 16 B7 DA 56 C4 58 F4 > [INT] Successfully set WEP key [2] > ath0 3 key sizes : 40, 104, 128bits > 4 keys available : > [1]: 487F-FBE7-3D7C-E14F-5A31-BD8D-D6 (104 bits) > [2]: 92AB-E32A-07B0-16B7-DA56-C458-F4 (104 bits) > [3]: off > [4]: off > Current Transmit Key: [2] > Security mode:open > > Notice above that we are NOT setting the transmit index here as we did > with the unicast key, but the driver sets the transmit index to 2 > anyway. At this point traffic no longer flows *correctly* because the > driver is using the wrong transmit key. > > Ok, now I'm going to jump over to the HEAD branch patch that was > submitted by Paul Stewart of Xerox PARC, because I think I can explain > that patch now that I understand more completely what is going on. > > First change: > > int kid, error, wepchange = 0, zerokey = 0, i; > > "zerokey" was added, and wepchange and zerokey were initialized to 0: > > > Second Change: > > for (i = 0; i < erq->length && keybuf[i] == 0; i++); > zerokey = (i == erq->length); > > I'm not exactly sure what's going on here, other than zerokey is being > set to true (1) if the key should be set as the txkey (that is, if the > key is 0 length): > > Third Change: > > And finally, if the key length is zero, we need to set this key as the > txkey, because we *only* want to set the txkey when a zero-length key > is set with the wireless API (as per the man page for iwconfig): > > if (zerokey) { > ic->ic_wep_txkey = kid; > wepchange = (ic->ic_flags & IEEE80211_F_WEPON) == 0; > ic->ic_flags |= IEEE80211_F_WEPON; > } > > And here is the man page excerpt: > > key/enc[ryption] > Used to manipulate encryption or scrambling keys > and security mode. > To set the current encryption key, just enter the > key in hex digits as XXXX-XXXX-XXXX-XXXX or > XXXXXXXX. To set a key other than the current key, > prepend or append [index] to the key itself (this > won't change which is the active key). You can also > enter the key as an ASCII string by using the s: > prefix. Passphrase is currently not supported. > To change which key is the current active key, just > enter [index] (without entering any key value). > > Xsupplicant is basically doing something like "iwconfig ath0 key [1]" > internally to set the transmit key (where [1] is the index sent in the > key message from the AP). Unfortunately, the MADWifi driver, in its > current incarnation without the above patched pieces, is setting every > new key as the transmit key, which is incorrect from an 802.1X > standpoint, since only unicast key messages should be interpreted and > set as the transmit key. (Other Linux drivers "behave correctly" in > this regard). > > So, Paul's patch fixes this problem in HEAD. A different patch will be > needed for WPA branch, since the code base is different... but > hopefully this helps clarify things. > > And for completeness, here is Paul's patch once again. > > Does that help, Sam? > > Thanks! > > - Terry > > |