The Gatekeeper

Wireless users are accustomed to the ritual of providing login information before they connect to a local network. The IEEE 802.1X standard [1] defines a technique for port-based network access control that is used with most wireless access points.

Many admins don't realize IEEE 802.1X can also provide access control for conventional (wired) networks. The IEEE 802.1X authentication scheme actually offers several advantages over alternatives such as MAC-based port authentication, which is easily sniffed and often difficult to manage.

In the age of netbooks, an unauthorized laptop can plug in from almost anywhere on the network. Wary admins looking for better protection can use IEEE 802.1X to stop unauthorized access before the intruder reaches a browser window or login screen.

Unblocking a Port

The IEEE 802.1X authentication environment includes three components:

• Supplicant – The client requesting access to the network;
• Authenticator – An Ethernet switch or access point through which the supplicant is requesting access;
• Authentication server – A server on the network that maintains an authentication database and communicates with the authenticator to approve or deny the access request.

In the case of a home wireless access point, the authenticator and authentication server are often enclosed in the same simple device. On a wired LAN, the situation is a bit more complicated. Many corporate-grade managed switches provide built-in support for IEEE 802.1X. A properly configured switch is thus well suited to serving the role of authenticator, receiving access requests from clients and communicating with a back-end server – typically using the popular RADIUS authentication protocol.

Before the switch (which in RADIUS context is referred to as the Network Access Server – NAS) permits any kind of traffic via one of its ports, which the standard refers to as Port Access Entities (PAE), the requesting device – typically a desktop or laptop computer – has to undergo an authentication process. This authentication occurs in the Data Link Layer and relies on the Extensible Authentication Protocol (EAP). The requesting device needs to run a small client program (the supplicant). The client presents its credentials in the form of a special Ethernet frame called an EAPoL.

EAP supports a variety of credentials, but X.509v3 client certificates are a common option. The certificates support a strict cryptographic standard and can be managed both individually, and, if necessary, via a public key infrastructure (PKI) using the EAP-TLS protocol extension [2]. Other options include One-Time Password (OTP), Protected EAP (PEAP), or tunneled TLS (TTLS).

When the switch receives an EAP-Response/Identity EAP request, it forwards the request to a Remote Access Server (RAS) that is serving as the authentication server. The RAS system knows all the permissions and informs the switch of the results of the authentication check. If the check is positive, the switch opens the PAE, and the client can then access the network to take an action such as grabbing an IP address through DHCP.

Authentication on Board

Many managed switches support IEEE 802.1X. The Netgear FSM726, which sells for around US$ 200 with its 2Gb ports; the 3Com 2924-SFP Plus, which goes for around US$ 270; and the US$ 340 Level One GSW-2494 are a few examples. All of these devices have 24 ports and differ with respect to features.

Almost all of these switches include a web interface (Figure 1), and some of them use a command-line interface for configuration, such as Cisco's IOS. Article 5.1 of the 802.1X standard defines the requirements for switches. Some of them, such as the IOS-based switches, provide additional features, such as a guest VLAN, into which supplicants without valid credentials are dumped by the NAS. (This guest VLAN option is useful for visitors or conferences.)

Figure 1: A web-based configuration front end. The Netgear FSM726 Managed Switch has 24 ports that can be configured individually to support IEEE-802.1X Auto operations.

To enable Network Access Control on the switch, the system administrator needs to switch the ports (PAEs) from Authorized mode to Auto mode and give the network device the password and IP address of the Remote Access Server. It is good idea to add a separate VLAN with an isolated admin subnet and set the port to Authorized to avoid "chicken/egg" issues.

RADIUS Manages Users

The switch uses the RADIUS protocol (which is defined in RFC 2865) to talk to the RAS server. The communications are protected by a shared secret, which the administrator can generate with the comand pwgen -s -1 and then store on the switch.

With this step, the administrator has completed the preparations for the network device. All other server-side settings are performed on the RAS server. The RAS server is also where the certificates are managed, unless you prefer to keep them on a separate machine for security reasons.

FreeRADIUS [5] is a good choice as a remote access server. Just a few changes to the default configuration in /etc/raddb/(openSUSE) or /etc/freeradius/ (Ubuntu) let the administrator enable EAP-TLS. The basic FreeRADIUS settings are extended by adding various custom files. For example, the software can retrieve a user list from a database or directory service or impose time restrictions for users.

General settings are located in the radius.conf file. Because you only need the server to perform authentication, the listen section with type=auth is the most relevant setting. To prevent the software from listening on all interfaces for requests to UDP port 1812, you need to set the IP addresses for the ipaddr key. Additionally, you might need to modify your firewall rules. For easier traceability of requests, you can add an auth = yes entry to the log section of the radius.conf file.

The clients.conf file specifies the administrative segment that lies between the switch and the RAS server. The secret entry contains the secret shared by these two:

client 192.168.123.0/24 {
  secret = hEoLw6DC
  shortname = uebelhackers
}

The radius.conf file binds eap.conf, and this is where the default_eap_type key is set to tls. The password that enables the server certificate, which still needs to be created, is set in the same section that private_key_password was set.

Creating Certificates

Some distributions include a makefile in the /etc/raddb/certs directory. You can use this makefile in combination with OpenSSL to create three kinds of certificates: a certificate for (first) a small CA that will later sign the certificates for (second) the server and (third) the clients. However, if this directory is empty, as is the case with Ubuntu 9.04, you can grab the files from the FreeRADIUS GitHub at raddb/certs/ [6]. The package includes a configuration file for each certificate and a shared makefile. To create a new CA certificate, you need to modify ca.cnf. Modify the [certificate_authority] section as shown in Listing 2. The values for input_password and output_password must be identical.

To edit the [server] section in server.cnf, follow the same steps, but choose a different commonName to differentiate between the certificates (see Listing 3). Next, insert private_key_password, specified in eap.conf, as the password. Finally, make all will create both the CA and server certificates, the required Diffie-Hellman file (dh), and the random file, both of which are important components in the SSL/TLS handshake.

User Certificates

In EAP-TLS, each device needs its own client certificate, which you can create with client.cnf. The FreeRADIUS makefile signs these credentials with the server certificate by default. To use the CA to sign them, change the lines in Listing 4 and watch out for the tab at the start of line 2. You can then give the supplicants the CA certificates directly.

The commonName in the [client] section specifies the user name for permissions and other settings in RADIUS. Again, the certificate is password-protected using the passwords set as input_password and output_password:

[client]
countryName = DE
stateOrProvinceName = Hamburg
localityName = Hamburg
organizationName = UebelHacker
emailAddress = s@uebelhacker.de
commonName = uebelacker

In contrast to the CA and server certificates, you need to create multiple certificates here – one for each user. As make client only creates one certificate, it makes sense to script this task. You can then hand out the certificates, passwords, and the CA certificate to the users in a secure manner, preferably on a USB stick or smartcard.

Setting up Users

The next things the RAS server needs are the details of the authorized users. To keep this simple, you can simply give each user a client certificate signed by the CA. If you don't change the users configuration file on the RADIUS server, it will give access to anybody with a valid certificate. The switch will then assign the supplicant to the specified VLAN.

However, if you prefer to give the RAS server more details about the users, a number of options are available for doing so: The fastest approach would be to add the authorized and non-authorized users to the users file. See Listing 5 for an example of this method.

Line 3 of Listing 5 defines the defaults for any supplicant that provides a valid certificate via EAP. The Tunnel-Type and Tunnel-Medium details are required by the standard if you want the switch to assign a VLAN – for example, 23 as the user segment. RFC 2869 defines more RADIUS extensions; for example, you can restrict user logins to weekdays between 8am and 8pm to prevent night hacking sessions.

The first line blocks the user dau, who has just left the company but still has a valid certificate. As an alternative, you could implement this business logic with Certificate Revocation Lists (CRLs), although this step is slightly more complex. The first match rule applies for this file, unless you have set the Fall-Through attribute as shown in line 7. The additional attributes overwrite the settings for the administrator, uebelacker, who is not subject to time restrictions and lands directly in the administrative segment.

radiusd -X launches the RAS in debug mode to identify any incorrect configurations. If the server launches cleanly, RADIUS will show that it is now responding to requests:

Listening on authentication address 192.168.123.23 port 1812
Ready to process requests.

It makes sense to run the daemon in debug mode until the network port is unlocked; this will log any activities verbosely on standard output.

Monitoring

In production use, you can monitor these activities by entering tail -f /var/log/radius/radius.log:

Info: Ready to process requests.
Auth: Login OK: [uebelacker] (from client uebelhackers port 13 cli 00:19:e0:18:38:5c)

This output indicates that the owner of the certificate issued to uebelacker has logged in to switch port 13. Both Xsupplicant from the OpenSEA Alliance's [7] Open1X project [8] and the slightly better known wpa_supplicant [9] support this type of supplicant login. However, some distributions do not include these two supplicants. On Ubuntu 9.04, the Network Manager acts as a graphical front end for wpa_supplicant (see Figures 2 and 3).

Figure 2: The Ubuntu Network Manager is familiar with the EAP Transport Layer Service (TLS) and offers a graphic configuration interface.

Figure 3: Once the configuration is complete, logging on at the switch is transparent for users.

On the Client

The user needs to configure an 802.1X profile in /etc/xsupplicant/xsupplicant.conf (see Listing 6), which can be tested by calling the supplicant as follows:

xsupplicant -D wired -i eth0 -d 5 -f -c /etc/xsupplicant/xsupplicant.conf

Following 802.1X authentication and the unlocking of the network port, which the tool indicates by announcing Changing from AUTHENTICATING to AUTHENTICATED, the start script assigns either a static IP or uses DHCP in the normal way. If the Xsupplicant is run in the background using /etc/init.d/xsupplicant start, and survives a reboot thanks to chkconfig xsupplicant on, 802.1X authentication will take place automatically.

Testing

The wpa_supplicant package provides a means for testing the configuration:

wpa_supplicant -i eth0 -D wired -c /etc/wpa_supplicant/wired.conf

Now you need to create a wired.conf configuration file, as specified in Listing 7. Because 802.1X authentication is wire based, you can use version 2 of eapol_version and disable the access point scan.

The supplicant announces CTRL-EVENT-EAP-SUCCESS in the case of a successful authentication. To run the client permanently in the background and authenticate the client automatically in case of 802.1X ports, users need to modify /etc/network/interfaces, as shown in Listing 8 for Debian – assuming they use DHCP. Otherwise, change dhcp to static and define a static IP address. /etc/init.d/networking restart enables these settings. If the client achieves authorized state via a non-IEEE 802.1X port, the login attempt will be redundant, but the client will work normally.

Production

The last step for the administrator is to set the RADIUS server to production mode: enable the init script using service freeradius start, and type chkconfig freeradius on to set up the server to use the same start procedure when rebooted.

Conclusion

The components for device-based authentication of terminal devices exist in many environments. It is up to the administrator to combine those components.

For some people, Network Access Control includes additional aspects, such as technical validation of version status or up-to-date virus signatures, in line with a security policy. NAC offers a number of customization options: Besides LDAP or SQL database integration, more complex environments might want to deploy a PKI with the use of Tiny CA [10], for example. Smartcards such as the Aladdin E-Token protect private user certificates.

IPv6 is supported with FreeRADIUS Version 2 or later; however, some 802.1X-capable switches might not comply. If you are experimenting with IKEv2, check out the project's experimental.conf.

An identically named SourceForge project is also researching IKEv2 [11]. Thanks to the Hostapd project [12], administrators can soon look forward to a new implementation of EAP in FreeRADIUS known as EAP2.