802.1x on Linux with xsupplicant

In addition to having up-to-date wireless support in the kernel, you need to have a properly configured wireless networking subsystem. Many “wireless” problems encountered when dealing with 802.1x on Linux are PC card configuration problems. When the card is inserted, you should get a high-pitched beep indicating that Card Services has loaded the right driver. A second beep is used to communicate the status of the card configuration, so a second lower beep is fine because the configuration of the card hasn't been set up yet.

If the card is recognized and the right driver is loaded, try firing up a wireless network with no encryption and no authentication. Configure association to the network with iwconfig, and bring up the card with ifconfig. The MADwifi driver creates interfaces that begin with the prefix ath, so my interface is ath0. Depending on the driver you use, your interface may be different. When the card first comes up, you can see it scan for the network as the frequency reported by iwconfig changes. When the card successfully associates to a network, it reports the access point MAC address as well as the operating frequency. At that point, you should be able to ask the network for an IP address, using whatever tool is favored by your Linux distribution:

# iwconfig ath0 essid "clearnet"
# ifconfig ath0 up
# iwconfig ath0
ath0  IEEE 802.11g  ESSID:"etherclear"
      Mode:Managed  Frequency:2.412 GHz  Access Point: 00:0B:0E:2F:0A:40
      Bit Rate:12 Mb/s   Tx-Power:50 dBm   Sensitivity=0/3
      Retry:off   RTS thr:off   Fragment thr:off
      Power Management:off
      Link Quality=39/94  Signal level=-56 dBm  Noise level=-95 dBm
      Rx invalid nwid:107  Rx invalid crypt:0  Rx invalid frag:0
      Tx excessive retries:22  Invalid misc:22   Missed beacon:0
# dhcpcd -d -t 10 ath0
dhcpcd: MAC address = 00:20:a6:4c:ca:4b
dhcpcd: your IP address = 172.16.199.84

If you can associate to a network, your card is functional. Although it is not necessary to find out if you can obtain an IP address from an unencrypted network, it is helpful to know that the frame handling and network stacks are working and that DHCP service is configured correctly on the network. With the wireless network system having basic functionality, we can move on to providing security for it.

Two major supplicants exist for Linux: xsupplicant, also known as Open1X, and wpa_supplicant. This article discusses only the former. Before getting to work on xsupplicant, check the version of OpenSSL on your system. xsupplicant requires OpenSSL 0.9.7 or later to provide transport layer security (TLS) support. All the commonly used 802.1x authentication protocols require TLS, either for authentication directly with digital certificates (EAP-TLS) or as a protective tunnel for some other form of authentication (TTLS or PEAP). You need a development version of the packages to get the expected headers.

Download the source code from SourceForge (see Resources) At the time of this writing, the current release is 1.2pre1:

$ tar -xzf Xsupplicant-1.2pre1.tar.gz
$ cd xsupplicant
$ ./configure --with-madwifi-path=~/madwifi
. . .
Adding MADWIFI WPA support.
. . .
$ make

# make install

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

Secured EAP authentication generally depends on digital certificates. Certificate data is encoded using either the privacy-enhanced mail (PEM) format or the distinguished encoding rules (DER). My experience is that xsupplicant likes its certificates in PEM format, but many certificate authorities hand out certificates in the DER format. Fortunately, OpenSSL is quite good at converting between formats:

# openssl x509 -inform DER -outform PEM \
-in MyCA.der -out MyCa.pem

To see the actual data encoded within the certificate, you can use the openssl command to print textual output:

# openssl x509 -in MyCA.pem -text

How exactly you obtain the certificate is up to your network administrator. Many certificate authorities make the root certificate available on a Web page.

When run, xsupplicant searches for its configuration file in /etc. The config file, /etc/xsupplicant.conf, is not installed by default, but it's easy enough to copy over:

# cp xsupplicant.conf /etc/xsupplicant.conf

Specify the user identity, possibly the password and the root CA certificate in the configuration file. Each network can have its own configuration by bracketing the entire network configuration. A simple configuration for a network that uses PEAP with MSCHAP-V2 for inner authentication might look something like this:

dynamic-wep
{
  allow_types=all
  identity = testuser
  eap_peap {
      root_cert = /usr/local/etc/myCA.der
      random_file = /path/to/random/source
      allow_types = eap_mschapv2
      eap-mschapv2 {
        username = testuser
        password = "testpw"
      }
  }
}

Linux has two random number devices, /dev/random and /dev/urandom. Both pull random numbers from a system entropy pool, but the former device returns only strong random numbers. As a result, I highly recommend using /dev/random as the random number device file. Many 802.1x implementations can cope with relatively large delays while waiting for a response. At the Interop Labs in Las Vegas in May 2005, we authenticated a user account through a multi-hop global distributed RADIUS system, so end-to-end latency was much higher than on most networks.

For testing purposes, certificate validation can be disabled by setting the root_cert location to NONE. Although useful for testing purposes, disabling certificate authentication removes the protections provided by the certificate and should not be done for normal deployments.