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.