Thread: [Madwifi-devel] Suggestion + Patch: static WEP and iwconfig
Status: Beta
Brought to you by:
otaku
From: Christian P. S. <sc...@di...> - 2006-07-27 19:47:30
Attachments:
iwconfig-wep.patch
|
Hi all, I recently tried to connect to a Cisco Linksys access point (WRT54GC). Worked smooth withput encryption (initial test). Sadly, worked neither with WPA/WPA2 nor WEP. Trying to exclude wpa_supplicant as a possible source of error I focused on WEP for the beginning. After some debugging I found that madwifi tried an open auth handshake even after I set a key with iwconfig. The attached patch for the SIOCSIWENCODE ioctl() sets the auth scheme depending on the privacy flag for the VAP, fixing it to shared auth if WEP keys are set and open auth otherwise. I'm not too sure about the behavior if WPA is used though. The correct behavior would be to set it to open auth even if the privacy flag is set, so with this patch applied it would be needed to first remove any existing WEP keys before WPA can be enabled. Another possible idea to get this going would be to change the checks in ieee80211_send_mgmt (ieee80211_output.c) regarding the checks for IEEE80211_FC0_SUBTYPE_AUTH in a way that shared auth is enabled if the arg is IEEE80211_AUTH_SHARED_REQUEST and a key is set, even if vap->iv_bss->ni_authmode is set to IEEE80211_AUTH_OPEN. This would allow for both open and shared key auth at the same time, though it might lead users to a false sense of security if they set a key and yet operate without encryption. Thanks for the all of the work on drivers! Best regards, Christian |
From: Christian P. S. <sc...@di...> - 2006-07-27 21:18:15
Attachments:
0.9.1.iwconfig-wep.patch
0.9.2.iwconfig-wep.patch
|
Hi all, Sorry for sending an obsolete patch with the last mail. Mail below duplicated. I recently tried to connect to a Cisco Linksys access point (WRT54GC). Worked smooth withput encryption (initial test). Sadly, worked neither with WPA/WPA2 nor WEP. Trying to exclude wpa_supplicant as a possible source of error I focused on WEP for the beginning. After some debugging I found that madwifi tried an open auth handshake even after I set a key with iwconfig. The attached patch for the SIOCSIWENCODE ioctl() sets the auth scheme depending on the privacy flag for the VAP, fixing it to shared auth if WEP keys are set and open auth otherwise. I'm not too sure about the behavior if WPA is used though. The correct behavior would be to set it to open auth even if the privacy flag is set, so with this patch applied it would be needed to first remove any existing WEP keys before WPA can be enabled. Another possible idea to get this going would be to change the checks in ieee80211_send_mgmt (ieee80211_output.c) regarding the checks for IEEE80211_FC0_SUBTYPE_AUTH in a way that shared auth is enabled if the arg is IEEE80211_AUTH_SHARED_REQUEST and a key is set, even if vap->iv_bss->ni_authmode is set to IEEE80211_AUTH_OPEN. This would allow for both open and shared key auth at the same time, though it might lead users to a false sense of security if they set a key and yet operate without encryption. Thanks for the all of the work on drivers! Best regards, Christian |
From: Brian E. <eat...@gm...> - 2006-07-28 18:52:00
|
On 7/27/06, Christian P. Schmidt <sc...@di...> wrote: > The attached patch for the SIOCSIWENCODE ioctl() sets the auth scheme > depending on the privacy flag for the VAP, fixing it to shared auth if > WEP keys are set and open auth otherwise. This is incorrect. It is perfectly reasonable to use open authentication with WEP encryption. In fact, the connection is more secure if you do so. WEP shared key authentication uses some poorly designed cryptography. Using WEP with open authentication doesn't mean that everybody can use your AP either, since they still need the WEP key. If you want to be able to set the authentication mode, check out "iwpriv <intf> authmode". If you can put together a patch that allows madwifi to automatically detect whether the AP is using open vs shared-key auth and adjust appropriately, that would be best. Regards, Brian |
From: Pavel R. <pr...@gn...> - 2006-07-28 07:57:45
|
Hello! Quoting "Christian P. Schmidt" <sc...@di...>: > I recently tried to connect to a Cisco Linksys access point (WRT54GC). > Worked smooth withput encryption (initial test). Sadly, worked neither > with WPA/WPA2 nor WEP. > > Trying to exclude wpa_supplicant as a possible source of error I focused > on WEP for the beginning. After some debugging I found that madwifi > tried an open auth handshake even after I set a key with iwconfig. > The attached patch for the SIOCSIWENCODE ioctl() sets the auth scheme > depending on the privacy flag for the VAP, fixing it to shared auth if > WEP keys are set and open auth otherwise. I object. Shared key authentication is known to be less safe because is allows to brute force the WEP key by continuous authentication requests. MadWifi defaults to a safer authentication method, which is the right thing to do. Of course, it could be argued that WEP is unsafe in any configuration, but then again, why change the code for no benefit and expose users to possible breakage if they rely on the current default? > I'm not too sure about the behavior if WPA is used though. The correct > behavior would be to set it to open auth even if the privacy flag is > set, so with this patch applied it would be needed to first remove any > existing WEP keys before WPA can be enabled. WPA used open system authentication. I don't think we want to change the driver to create another possibility for failure (running wpa_supplicant without clearing the WEP keys). > Another possible idea to get this going would be to change the checks in > ieee80211_send_mgmt (ieee80211_output.c) regarding the checks for > IEEE80211_FC0_SUBTYPE_AUTH in a way that shared auth is enabled if the > arg is IEEE80211_AUTH_SHARED_REQUEST and a key is set, even if > vap->iv_bss->ni_authmode is set to IEEE80211_AUTH_OPEN. This would allow > for both open and shared key auth at the same time, though it might lead > users to a false sense of security if they set a key and yet operate > without encryption. Are you suggesting that the driver tries both methods sequentially? I don't see you one can set the key but operate without encryption. If the key is set, it's used for transmission. For others to be able to decrypt the packet, they should know the key. If they know the key, they would use it for transmission as well (in the default case, at least). Probably I don't understand the scenario you have in mind. -- Regards, Pavel Roskin |
From: Christian P. S. <sc...@di...> - 2006-07-28 08:52:51
|
Hi, First of all, my post was a case of severe PEBCAK. I blame google for not pointing me to docs/WEP-HOWTO.txt ;) Now for the real thing... Pavel Roskin wrote: > Hello! > > Quoting "Christian P. Schmidt" <sc...@di...>: > >> I recently tried to connect to a Cisco Linksys access point (WRT54GC). >> Worked smooth withput encryption (initial test). Sadly, worked neither >> with WPA/WPA2 nor WEP. >> >> Trying to exclude wpa_supplicant as a possible source of error I focused >> on WEP for the beginning. After some debugging I found that madwifi >> tried an open auth handshake even after I set a key with iwconfig. >> The attached patch for the SIOCSIWENCODE ioctl() sets the auth scheme >> depending on the privacy flag for the VAP, fixing it to shared auth if >> WEP keys are set and open auth otherwise. > > I object. Shared key authentication is known to be less safe because is allows > to brute force the WEP key by continuous authentication requests. MadWifi > defaults to a safer authentication method, which is the right thing to do. > > Of course, it could be argued that WEP is unsafe in any configuration, but then > again, why change the code for no benefit and expose users to possible breakage > if they rely on the current default? I have to agree, and want to discard my earlier patch. >> I'm not too sure about the behavior if WPA is used though. The correct >> behavior would be to set it to open auth even if the privacy flag is >> set, so with this patch applied it would be needed to first remove any >> existing WEP keys before WPA can be enabled. > > WPA used open system authentication. I don't think we want to change the driver > to create another possibility for failure (running wpa_supplicant without > clearing the WEP keys). Exactly. That was why I pointed this out. >> Another possible idea to get this going would be to change the checks in >> ieee80211_send_mgmt (ieee80211_output.c) regarding the checks for >> IEEE80211_FC0_SUBTYPE_AUTH in a way that shared auth is enabled if the >> arg is IEEE80211_AUTH_SHARED_REQUEST and a key is set, even if >> vap->iv_bss->ni_authmode is set to IEEE80211_AUTH_OPEN. This would allow >> for both open and shared key auth at the same time, though it might lead >> users to a false sense of security if they set a key and yet operate >> without encryption. > > Are you suggesting that the driver tries both methods sequentially? > > I don't see you one can set the key but operate without encryption. If the key > is set, it's used for transmission. For others to be able to decrypt the > packet, they should know the key. If they know the key, they would use it for > transmission as well (in the default case, at least). > > Probably I don't understand the scenario you have in mind. In fact the driver sees the type of request from the AP. To quote from ieee80211_output.c: /* * Deduce whether we're doing open authentication or * shared key authentication. We do the latter if * we're in the middle of a shared key authentication * handshake or if we're initiating an authentication * request and configured to use shared key. */ is_shared_key = has_challenge || arg >= IEEE80211_AUTH_SHARED_RESPONSE || (arg == IEEE80211_AUTH_SHARED_REQUEST && vap->iv_bss->ni_authmode == IEEE80211_AUTH_SHARED); So, if arg is set to IEEE80211_AUTH_SHARED_REQUEST, the AP requests a shared key auth. The bad thing (for me) is that the driver additionally checks what the user has put in. I can see provisioning for IEEE80211_AUTH_AUTO in 0.9.2 and SVN. Basically automatic is what I'd want - if the AP requests shared auth and we are prepared e.g. having a key, do shared auth, otherwise do open auth. This would look like: is_shared_key = has_challenge || arg >= IEEE80211_AUTH_SHARED_RESPONSE || (arg == IEEE80211_AUTH_SHARED_REQUEST && ((vap->iv_bss->ni_authmode == IEEE80211_AUTH_SHARED) || ((vap->iv_bss->ni_authmode == IEEE80211_AUTH_AUTO) && (vap->iv_flags & IEEE80211_F_PRIVACY) && (vap->iv_nw_keys[vap->iv_def_txkey].wk_keylen > 0)))); Then I'd just love to see the automatic mode becoming default, but that's another story ;) Regards, Christian > -- > Regards, > Pavel Roskin |
From: Brian E. <eat...@gm...> - 2006-07-29 05:35:45
|
On 7/28/06, Christian P. Schmidt <sc...@di...> wrote: > Then I'd just love to see the automatic mode becoming default, but > that's another story ;) Thanks for the research, Christian. A fair number of the problems in trac have to do with people having shared vs open auth mode set incorrectly. If we change madwifi to figure this out automatically, are we introducing security vulnerabilities? e.g. could an attacker gain an advantage by spoofing shared key authentication packets? What do other wireless drivers do? Regards, Brian |
From: Cedric B. <bla...@ca...> - 2006-08-13 13:10:10
|
Le vendredi 28 juillet 2006 =E0 22:35 -0700, Brian Eaton a =E9crit : > If we change madwifi to figure this out automatically, are we > introducing security vulnerabilities? e.g. could an attacker gain an > advantage by spoofing shared key authentication packets? Example scenario... Wpa_supplicant is used as some wireless connection manager, trying all defined networks one after the other. I can answer all authentication requests, a bit like Karma[1] tool does, but asking for a challenge. If a WEP enable network is tested, than I will be able to provide driver with choosen plaintext challenges, thus having them decrypted by client. Then I can keep on refusing challenge answer and keep rolling. Not very likely to happen, but eventually, it can lead to IV/RC4 outputs table construction or WEP key cracking. --=20 http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! |