1X on Linux with xsupplicant

X on Linux with xsupplicant

I have been fortunate enough to volunteer at the Interop Labs wireless security initiatives for the past few years, where I get to experience interoperability close up. In 2004, developers from the Open1X project participated in the interoperability test event, bringing open source code into an event that had previously been the preserve of product manufacturers. As the popularity of wireless networks has waxed, so has interest in solutions for connecting Linux systems to secure wireless LANs. xsupplicant is one of the leading implementations of 802.1X for Linux.

Requirements

Before even considering working with xsupplicant, the most important task is to ensure that 802.11 is already working! Many "wireless" problems are really PC Card problems. Obviously, you will not be able to attach to an authenticated network until building and configuring xsupplicant, but you should be able to insert your wireless card and have it recognized by the system. Card Services will generally sound a high-pitched beep when a card is inserted to indicate it is recognized, resources were successfully allocated, and the driver was loaded. (A second low-pitched beep may follow indicating a configuration failure, but that is okay. Chances are that you want your ultimate configuration to run xsupplicant, so it's acceptable at the outset to not have configuration support immediately.) With the driver successfully loaded, you should be able to run iwconfig and obtain statistics from the driver.

Even if the driver for your chosen card is working, make sure it has support for dynamic WEP. Although there is some dispute over the absolute security level of dynamically keyed WEP systems, it is unquestionable that dynamic WEP has a significantly higher level of security than a single-key WEP system. It is a virtual certainty that any card you want to use with xsupplicant should support the use of dynamic keys. Most modern cards, those released in early 2003 and later, have driver support for dynamic WEP already, but a few older cards require patches. The popular Hermes-based Orinoco 802.11b cards fall into the latter category. Depending on the driver, you may also need to rebuild your kernel (or at least get a copy of your kernel's configuration) in order to compile a driver.

Finally, xsupplicant needs one major library. As discussed previously, most EAP methods are based on TLS in one way or another. xsupplicant uses the OpenSSL TLS implementation. Install version 0.9.7 or later. Before fetching the source from openssl.org, check to see if there is a package available for your distribution.

Compiling and Installing xsupplicant

Compiling and installing xsupplicant follows the same routine that any other open-source package. Released code can be fetched from http://sourceforge.net/projects/open1x/, and compiled in the standard Unix way:

 root@bloodhound:~# tar -xzvf xsupplicant-1.0.1.tar.gz
 root@bloodhound:~# cd xsupplicant
 root@bloodhound:~/xsupplicant# ./configure
 root@bloodhound:~/xsupplicant# make
 root@bloodhound:~/xsupplicant# make install

As this book went to press, xsupplicant 1.0.1 was several months old, and massive development had occurred in the CVS version. (This section is written using a late 2004 CVS version.) Among many other improvements, the CVS version has preliminary WPA support. The CVS version can be fetched from an anonymous CVS server, and compiled in the standard Unix way:

 root@bloodhound:~# cvs -z3 -d:pserver:[e-mail]:/cvsroot/xsupplicant co xsupplicant
 root@bloodhound:~# cd xsupplicant
 root@bloodhound:~/xsupplicant# ./configure
 root@bloodhound:~/xsupplicant# make
 root@bloodhound:~/xsupplicant# make install

As a result of the build, you get three executables installed; the only one you are likely to use is /usr/local/sbin/xsupplicant.

Configuring xsupplicant

When run, xsupplicant searches for its configuration file in /etc. The config file, /etc/xsupplicant.conf, does not get installed by default, so copy it over to the expected location.

 root@bloodhound:~/xsupplicant# cp etc/xsupplicant.conf /etc/

Configuration files specify the authentication method, user identity, possibly the password, and a certificate location to validate the certificate from the network. Certificate authentication of the network may be disabled by setting the certificate location to NONE, but it is not recommended. When setting up the network, you may need to convert certificates between different forms. OpenSSL can easily convert between different formats by specifying the formats on the command line.

 root@bloodhound:~# openssl x509 -inform DER -outformPEM -in MyCA.der -out MyCa.pem

Passwords are stored in the configuration file in a nonencrypted form, so you may wish to have the system prompt for the password to avoid putting sensitive information in configuration files. When no password is in the file for the network you are connecting to, xsupplicant will prompt the user.

In the configuration file, settings can be stored as part of a profile for an SSID. The following example is a simple configuration for a network using PEAP, with EAP-MSCHAP-V2 inner authentication on a network called batnet. xsupplicant can be configured to run a command after authentication completes, or that can be left to the configuration scripts on the operating system.

 ### GLOBAL SECTION

 logfile = /var/log/xsupplicant.log
 network_list = all
 default_netname = batnet

 first_auth_command = dhcpcd %i

 ### NETWORK SECTION

 batnet{
 # allow_types = eap_tls, eap_md5, eap_gtc, eap-otp
 allow_types = eap_peap

 # Phase 1 ("outer") identity
 identity = msg
 # Alternative, but common specification is to not reveal username
 # identity = anonymous

 eap-peap {
 # It is a good idea to validate the certificate and not do "none"
 # root_cert = NONE
 root_cert = rootCA.pem
 root_dir = /etc/xsupplicant.d
 chunk_size = 1398
 random_file = /dev/random

 # ** Inner method configuration
 allow_types = eap_mschapv2

 # Inner method configuration
 eap-mschapv2 {
 username = msg
 password = imnottelling
 }
 }
 }

 

Pseudorandom number generation

Like many other security protocols, EAP methods require a "good" source of random numbers. Linux provides two random number devices, /dev/random and /dev/urandom. The former returns random bits that are within the system's entropy pool. If insufficient entropy is available, the read will block until sufficient entropy is available, while the latter will return as much data is requested, perhaps at the cost of quality.

Connecting and Authenticating to a Network

The first step in gaining access to an 802.1X-protected network is to associate to it. xsupplicant depends on the system to perform the association. The initial configuration should also configure the card to use encrypted frames, although the key configured does not matter. Configure a dummy key to indicate to the driver that it should run in encrypted mode; xsupplicant will replace the key after successful authentication with a wireless extension library call. The most common way of configuring the connection is to use iwconfig to plumb a key and configure the network, and then use ifconfig to bring the interface up and start searching for the network. Naturally, these commands may be triggered by the configuration system scripts when a wireless card is inserted.

 root@bloodhound:~# iwconfig ath0 key 12345678901234567890123456
 root@bloodhound:~# iwconfig essid essid "batnet"
 root@bloodhound:~# ifconfig ath0 up

After the system has associated with the network, run xsupplicant. The -i option indicates which interface it should run on. Debugging is activated with -d, with the following letters determining what information is printed out. Log messages are sent to the console with -f. The following example has cut the raw packet dumps.

 root@bloodhound:~# /usr/local/sbin/xsupplicant -i ath0 -dasic -f
 Using default config!
 network_list: all
 Default network: "default"
 Startup command: "echo "some command""
 First_Auth command: "dhclient %i"
 Reauth command: "echo "authenticated user %i""
 Logfile: "/var/log/xsupplicant.log"
 Allow Types: ALL
 ID: "msg"
 peap root_cert: "NONE"
 peap chunk: 1398
 peap rand: "/dev/random"
 PEAP Allow Types: ALL
 mschapv2 username: "msg"
 mschapv2 password: "imnottelling"
 Interface ath0 initalized!

At this point, xsupplicant has read the configuration file, and checks to see if the wireless interface is associated to an AP. If it is, the authentication process can begin.

 [INT] Interface ath0 is wireless!
 [INT] The card reported that the destination MAC address is now 00 0B 0E 00 F0 40
 [INT] Working with ESSID : batnet
 [CONFIG] Working from config file /etc/xsupplicant.conf.
 [STATE] (global) -> DISCONNECTED
 [STATE] Processing DISCONNECTED state.
 [STATE] DISCONNECTED -> CONNECTING
 [STATE] CONNECTING -> ACQUIRED
 [STATE] Processing ACQUIRED state.

Once the system has associated to an AP, it begins authenticating.

 Connection established, authenticating...
 [STATE] Sending EAPOL-Response-Identification
 [STATE] ACQUIRED -> AUTHENTICATING)
 [STATE] Processing AUTHENTICATING state.
 [STATE] Sending EAPOL-Response-Authentication
 ****WARNING**** Turning off certificate verification is a *VERY* bad idea! You should not use this mode outside of basic testing, as it will compromise the security of your connection!
 [AUTH TYPE] Packet in (1) :
 20
 [AUTH TYPE] Setting Key Constant for PEAP v0!
 [INT] Interface eth0 is NOT wireless!
 Userdata is NULL! We will probably have problems!
 [STATE] (global) -> DISCONNECTED
 [STATE] Processing DISCONNECTED state.
 [STATE] DISCONNECTED -> CONNECTING
 [STATE] Processing AUTHENTICATING state.
 [STATE] Sending EAPOL-Response-Authentication

At this point, a great deal of debugging output will appear as certificates are exchanged back and forth and validated by both sides of the conversation. Once the TLS tunnel is established, the debug output shows the inner authentication. In the case of EAP-MSCHAP-V2, the RADIUS server sends a challenge. Based on the challenge value and the shared secret, a response is generated.

 [AUTH TYPE] (EAP-MSCHAPv2) Challenge
 [AUTH TYPE] (EAP-MS-CHAPv2) ID : 2F
 [AUTH TYPE] Authenticator Challenge : C6 02 26 BE C3 E0 44 03 13 6E 1F BA F0 B3 1D 5A
 [AUTH TYPE] Generated PeerChallenge : 28 62 AA A2 8C 8E EB 82 D1 9B 2F 9A 54 67 93 2C
 [AUTH TYPE] PeerChallenge : 28 62 AA A2 8C 8E EB 82
 [AUTH TYPE] AuthenticatorChallenge : C6 02 26 BE C3 E0 44 03
 [AUTH TYPE] Username : msg
 [AUTH TYPE] Challenge : 48 E7 AA 53 54 52 98 62
 [AUTH TYPE] PasswordHash : C5 A2 37 B7 E9 D8 E7 08 D8 43 6B 61 48 A2 5F A1
 [AUTH TYPE] Response : 4D 96 51 8C 18 3A F7 C7 70 15 47 13 19 D8 D6 9B 36 00 AD E8 FA 9A 0F 28
 [AUTH TYPE] myvars->NtResponse = 4D 96 51 8C 18 3A F7 C7 70 15 47 13 19 D8 D6 9B 36 00 AD E8 FA 9A 0F 28
 [AUTH TYPE] response->NT_Response = 4D 96 51 8C 18 3A F7 C7 70 15 47 13 19 D8 D6 9B 36 00 AD E8 FA 9A 0F 28
 [AUTH TYPE] (EAP-MSCHAPv2) Success!
 [AUTH TYPE] Server authentication check success! Sending phase 2 success!

Once the system has successfully authenticated, the AP will supply keys. Keys are both encrypted and authenticated, using keys derived from the shared cryptographic keys from the phase 1 TLS exchange. Two key messages are sent, one with the unique unicast key for the station, and one with the broadcast key shared by all stations. xsupplicant uses the wireless extensions API to set the keys in the driver, where they will be viewable with iwconfig.

 Processing EAPoL-Key!
 [INT] Key Descriptor = 1
 [INT] Key Length = 13
 [INT] Replay Counter = 41 2F BB 2D 00 00 00 D5
 [INT] Key IV = 69 4C 45 D7 CF C3 DD CD 2A 3A F3 CB 04 7A F4 A3
 [INT] Key Index (RAW) = 01
 [INT] Key Signature = C2 05 6C 3A EB 25 E9 B9 8E FC 60 D6 77 44 57 22
 [INT] EAPoL Key Processed: broadcast [2] 13 bytes.
 [INT] Key before decryption : ED 5D 03 D2 7A DE B4 60 29 FD FD F5 42
 [INT] Key after decryption : FB BB AC D3 6F 7D 0A 3F FF 2A CF 33 4E
 [INT] Successfully set WEP key [2]
 Processing EAPoL-Key!
 [INT] Key Descriptor = 1
 [INT] Key Length = 13
 [INT] Replay Counter = 41 2F BB 2D 00 00 00 D6
 [INT] Key IV = 66 15 69 E2 B2 8C 0E 89 7C D3 94 8C 93 25 43 1B
 [INT] Key Index (RAW) = 80
 [INT] Key Signature = 49 C1 15 B8 E9 D0 87 53 A6 FD 5D 76 CB 51 9D 65
 [INT] EAPoL Key Processed: unicast [1] 13 bytes.
 [INT] Using peer key!
 [INT] Successfully set WEP key [1]
 [INT] Successfully set the WEP transmit key [1]

Some drivers implement private system calls to report keys. Atheros cards using the MADwifi driver can list keys with iwlist ath0 key; many drivers will also report the unicast key in iwconfig.

Commercial 802 1X on Linux

In addition to xsupplicant, there is one commercial program available from Meetinghouse Data Communications. Meetinghouse's AEGIS client supports a wide variety of EAP methods (MD5, TLS, TTLS, PEAP, and LEAP). Due to the difficulties in keeping up with new distributions, however, it is only officially supported on RedHat versions 8 and 9. The Linux version of the Meetinghouse supplicant does not support WPA for the same reason xsupplicant does not: the lack of a standard WPA keying API.

 

WPA on Linux

WPA is not generally available on Linux because there is no standard way of obtaining the necessary information to perform the four-way handshake. xsupplicant runs in user space, but some of the data necessary to compute the four-way handshake must be obtained through the driver. Each driver has defined its own system calls for fetching this data, which requires supplicants to track the development of private system calls in every driver. A future release of the wireless extensions API will support the necessary system calls, and WPA will be made available in both open source and commercial products.