802.1x automatic WEP key negotiation problems
Kyle Rose
krose+hostap
Tue Aug 26 07:29:06 PDT 2003
Sorry to spam the list if you guys got this already, but I got no
response and I wanted to make sure the list's mail problems didn't
blackhole the message. (The following two emails don't appear in the
archives, for instance.)
Cheers,
Kyle
Message 1:
Date: Sat, 23 Aug 2003 14:53:50 -0400
Last night, I successfully set up a HostAP/FreeRADIUS EAP/TLS
configuration on my firewall machine (PCMCIA->ISA bridge with a
Linksys WPC11 ver.3) and an xsupplicant configuration on my laptop
(Lucent Orinoco).
As far as I can tell, both cards have the latest firmware: 1.7.4 for
the Linksys, and whatever I managed to download from the Proxim
website the other day (maybe 8.10?).
At any rate, most everything works: the Linksys goes into AP mode,
shovels 802.1x frames from the laptop off to the hostapd, which then
contacts the FreeRADIUS server to initiate authentication, after which
the laptop is able to get DHCP request packets through to get an IP.
If the laptop doesn't have xsupplicant, or has an invalid certificate,
hostapd refuses to recognize its packets. Sounds great.
However, nothing at all works when I try to turn on WEP key
negotiation. Now, someone correct me if I'm wrong, but my impression
is that the xsupplicant and RADIUS server should together negotiate
some secure way for hostapd to send a WEP key to the laptop, initially
and perhaps at intervals, depending on whether one has re-keying
activated, no? Well, when I activate the encryption in hostapd.conf
by setting:
wep_key_len_broadcast=5
wep_key_len_unicast=5
then nothing happens when I plug the Lucent card into the laptop and
start xsupplicant: I see *nothing* in the logs after hostapd
successfully starts up, even at hostapd's highest log level; and the
Lucent card's lights just blink periodically, but it doesn't even find
my LAN's ESSID. The RADIUS server's configuration at this point is
moot, since hostapd never contacts it, presumably because it doesn't
see any of link negotiation frames from the laptop.
I've done the standard exhaustive-search things, like commenting out
one or the other of the above lines and restarting hostapd, to no
avail. I have been searching for hours on the web, newsgroup, and
relevant mailing lists, also in vain.
Let me give you the output of some relevant commands while the laptop
is attempting (futilely) to get authenticated. "yupa" is the firewall
machine containing the AP, and its LAN IP address is 192.168.16.1
(netmask 255.255.240.0). Feel free to ask me for anything you think
would help debug this problem.
As an added bonus, if someone can help me solve this, I'll write a FAQ
Q&A for this problem so others won't bother you. :)
root at yupa:~# uname -a
Linux yupa 2.4.21 #1 Wed Aug 20 20:27:29 EDT 2003 i586 GNU/Linux
root at yupa:~# lsmod | grep host
hostap_cs 47964 2
hostap 69796 0 [hostap_cs]
hostap_crypt_wep 3244 1 (autoclean)
hostap_crypt 1520 0 [hostap hostap_crypt_wep]
ds 6388 2 [hostap_cs]
pcmcia_core 43072 0 [hostap_cs ds i82365]
root at yupa:~# ifconfig
.
.
.
wlan0 Link encap:Ethernet HWaddr 00:06:25:AB:9D:84
inet addr:192.168.16.1 Bcast:192.168.31.255 Mask:255.255.240.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:3 Base address:0x100
wlan0ap Link encap:UNSPEC HWaddr 00-06-25-AB-9D-84-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:2290 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:78 (78.0 b)
Interrupt:3 Base address:0x100
root at yupa:~# iwconfig
.
.
.
wlan0 IEEE 802.11b ESSID:"valley-of-wind"
Mode:Master Frequency:2.422GHz Access Point: 00:06:25:AB:9D:84
Bit Rate:11Mb/s Tx-Power:-15 dBm Sensitivity=1/242700000
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:AFCC-CD41-B3 [2] Security mode:open
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
wlan0ap IEEE 802.11b ESSID:"valley-of-wind"
Mode:Master Frequency:2.422GHz Access Point: 00:06:25:AB:9D:84
Bit Rate:11Mb/s Tx-Power:-15 dBm Sensitivity=1/242700000
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:AFCC-CD41-B3 [2] Security mode:open
Power Management:off
wlan0sta IEEE 802.11b ESSID:"valley-of-wind"
Mode:Managed Frequency:2.422GHz Access Point: 00:00:00:00:00:00
Bit Rate:11Mb/s Tx-Power:-15 dBm Sensitivity=1/242700000
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:AFCC-CD41-B3 [2] Security mode:open
Power Management:off
root at yupa:~# hostap_crypt_conf -l wlan0
Default keys
algorithm: WEP
TX key idx: 2
key 1:
key 2: af cc cd 41 b3
key 3:
key 4:
root at yupa:~# for A in `prism2_param | egrep '^[[:space:]]+[a-zA-z0-9]*:' | sed -e 's@^[[:space:]]*@@' -e 's@:.*@@'`; do echo -n "$A: "; prism2_param wlan0 $A | sed -e 's@^wlan0.*_param:@@'; done
txratectrl: 0
beacon_int: 100
dtim_period: 1
pseudo_ibss: 0
other_ap_policy: 0
dump: 0
ap_max_inactivity: 300
ap_bridge_packets: 1
ap_nullfunc_ack: 0
max_wds: 16
autom_ap_wds: 0
ap_auth_algs: 3
monitor_allow_fcserr: 0
host_encrypt: 1
host_decrypt: 1
bus_master_threshold_rx: 0
bus_master_threshold_tx: 0
host_roaming: 0
bcrx_sta_key: 0
ieee_802_1x: 1
antsel_tx: 0
antsel_rx: 0
monitor_type: 0
wds_type: 4
hostscan: Interface doesn't accept private ioctl...
getprism2_param (8BE1): Operation not supported
ap_scan: 0
enh_sec: 0
basic_rates: 3
oper_rates: 15
hostapd: 1
ptype: 6
alc: Interface doesn't accept private ioctl...
getprism2_param (8BE1): Operation not supported
txpower: 13
root at yupa:~# cat /etc/hostapd/hostapd.conf
##### hostapd configuration file ##############################################
# Empty lines and lines starting with # are ignored
# AP netdevice name (without 'ap' prefix, i.e., wlan0 uses wlan0ap for
# management frames)
interface=wlan0
# hostapd event logger configuration
#
# Two output method: syslog and stdout (only usable if not forking to
# background).
#
# Module bitfield (ORed bitfield of modules that will be logged; -1 = all
# modules):
# bit 0 (1) = IEEE 802.11
# bit 1 (2) = IEEE 802.1X
# bit 2 (4) = RADIUS
#
# Levels (minimum value for logged events):
# 0 = verbose debugging
# 1 = debugging
# 2 = informational messages
# 3 = notification
# 4 = warning
#
logger_syslog=-1
logger_syslog_level=0
logger_stdout=-1
logger_stdout_level=0
# Debugging: 0 = no, 1 = minimal, 2 = verbose, 3 = msg dumps
debug=2
# Dump file for state information (on SIGUSR1)
dump_file=/tmp/hostapd.dump
# Daemonize hostapd process (i.e., fork to background)
daemonize=1
##### IEEE 802.11 related configuration #######################################
# SSID to be used in IEEE 802.11 management frames
ssid=valley-of-wind
# Station MAC address -based authentication
# 0 = accept unless in deny list
# 1 = deny unless in accept list
# 2 = use external RADIUS server (accept/deny lists are searched first)
macaddr_acl=0
# Accept/deny lists are read from separate files (containing list of
# MAC addresses, one per line). Use absolute path name to make sure that the
# files can be read on SIGHUP configuration reloads.
#accept_mac_file=/etc/hostapd.accept
#deny_mac_file=/etc/hostapd.deny
# IEEE 802.11 specifies two authentication algorithms. hostapd can be
# configured to allow both of these or only one. Open system authentication
# should be used with IEEE 802.1X.
# Bit fields of allowed authentication algorithms:
# bit 0 = Open System Authentication
# bit 1 = Shared Key Authentication (requires WEP)
auth_algs=1
# Associate as a station to another AP while still acting as an AP on the same
# channel.
#assoc_ap_addr=00:12:34:56:78:9a
##### IEEE 802.1X (and IEEE 802.1aa/D4) related configuration #################
# Require IEEE 802.1X authorization
ieee8021x=1
# Use internal minimal EAP Authentication Server for testing IEEE 802.1X.
# This should only be used for testing since it authorizes all users that
# suppot IEEE 802.1X without any keys or certificates.
minimal_eap=0
# Optional displayable message sent with EAP Request-Identity
eap_message=Unauthorized use punishable by death
# WEP rekeying (disabled if key lengths are not set or are set to 0)
# Key lengths for default/broadcast and individual/unicast keys:
# 5 = 40-bit WEP (also known as 64-bit WEP with 40 secret bits)
# 13 = 104-bit WEP (also known as 128-bit WEP with 104 secret bits)
wep_key_len_broadcast=5
wep_key_len_unicast=5
# Rekeying period in seconds. 0 = do not rekey (i.e., set keys only once)
#wep_rekey_period=300
# EAPOL-Key index workaround (set bit7) for WinXP Supplicant (needed only if
# only broadcast keys are used)
eapol_key_index_workaround=0
##### IEEE 802.11f - Inter-Access Point Protocol (IAPP) #######################
# Interface to be used for IAPP broadcast packets
#iapp_interface=eth0
##### RADIUS configuration ####################################################
# for IEEE 802.1X with external Authentication Server, IEEE 802.11
# authentication with external ACL for MAC addresses, and accounting
# The own IP address of the access point (used as NAS-IP-Address)
own_ip_addr=192.168.16.1
# RADIUS authentication server
auth_server_addr=127.0.0.1
auth_server_port=1812
auth_server_shared_secret=foobar
# RADIUS accounting server
acct_server_addr=127.0.0.1
acct_server_port=1813
acct_server_shared_secret=foobar
# Secondary RADIUS servers; to be used if primary one does not reply to
# RADIUS packets. These are optional and there can be more than one secondary
# server listed.
#auth_server_addr=127.0.0.2
#auth_server_port=1812
#auth_server_shared_secret=secret2
#
#acct_server_addr=127.0.0.2
#acct_server_port=1813
#acct_server_shared_secret=secret2
# Retry interval for trying to return to the primary RADIUS server (in
# seconds). RADIUS client code will automatically try to use the next server
# when the current server is not replying to requests. If this interval is set,
# primary server will be retried after configured amount of time even if the
# currently used secondary server is still working.
#radius_retry_primary_interval=600
So, my final question is: given that I use only authenticated
protocols for my own communication (e.g., SFS, SSH, https, etc.), and
mainly want authentication to keep others from piggy-backing on my
limited egress capacity, do I *need* WEP? To be more specific, is
EAP/TLS authentication worth anything without link-level encryption?
In my naive configuration, the AP seemed to reject any frames not from
an authenticated host, but just because I can't figure out how to get
them through doesn't mean it isn't possible. Regardless of the
answer, I'd still like to have WEP...but I need to know if this is a
show-stopper or not.
By the way, great work, guys. Despite the complexity of
configuration, most of it seems to work out of the box, and the rest
can probably be explained by the fact that I have only been using it
for about 24 hours now.
Cheers,
Kyle
Message 2:
Date: Sat, 23 Aug 2003 19:14:45 -0400
Kyle Rose <krose+hostap at krose.org> writes:
> Last night, I successfully set up a HostAP/FreeRADIUS EAP/TLS
> configuration on my firewall machine (PCMCIA->ISA bridge with a
> Linksys WPC11 ver.3) and an xsupplicant configuration on my laptop
> (Lucent Orinoco).
I love responding to my own emails.
So, I've made a bit more progress. First, I upgraded to 0.0.4 after
noticing that Debian only had 0.0.3.
Now, if I set:
#wep_key_len_broadcast=5
wep_key_len_unicast=5 # or 13, both work
then the laptop and the access point successfully negotiate a WEP key,
which appears on both systems:
AP
---
root at yupa:/usr/src/modules# hostap_crypt_conf -l wlan0
Default keys
algorithm: none
Keys for 00:60:1d:1c:bf:09
algorithm: WEP
TX key idx: 1
key 1: e8 bb d0 d7 30 bc e8 e4 7c 84 be 20 34
key 2:
key 3:
key 4:
laptop
------
the-book-of-life:~# iwconfig
.
.
.
Encryption key:E8BB-D0D7-30BC-E8E4-7C84-BE20-34
But, when I try to ping the AP from the laptop, nothing gets through
to the IP stack, though I do see lots of lines in /var/log/messages
indicating that hostap is throwing away stuff:
Aug 23 19:09:51 yupa kernel: wlan0: encryption configured, but RX frame not encrypted (SA=00:60:1d:1c:bf:09)
I just downloaded the latest copy of the archives, and Erich Schubert
(<erich at debian.org>) complained of the same problem only a few days
ago. So, I feel we are very close to the blocker here.
Incidentally, why does activating the broadcast WEP key cause the
behvaior I saw before (nothing getting through at all; no log messages
from hostap; etc.)?
Cheers,
Kyle
More information about the Hostap
mailing list