Network access control on wired networks with IEEE 802.1X

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.

Listing 2

Excerpt from ca.cnf

 

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.

Listing 3

Excerpt from server.cnf

 

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.

Listing 4

Modifying the Makefile for CA

 

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.

Listing 5

User Database

 

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.

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Radius and 802.1X

    The Radius protocol is typically used to authenticate users in dial-up scenarios. But Radius is also useful in LAN environments: in combination with 802.1X, Radius forces users to authenticate at a low level before the switch opens up a port.

  • iNet Wireless Daemon

    Intel's iNet wireless daemon offers virtually all of the features found in the obsolete WPA Supplicant, and it is smaller by a factor of 10.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News