Network access control on wired networks with IEEE 802.1X
The Gatekeeper
Did you think the IEEE 802.1X standard is only for wireless? We show you how to set up a network access
control system on a wired network with IEEE 802.1X and a FreeRADIUS server.
By Sven Übelacker and Nils Magnus
Konstantin Sutyagin, 123RF
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
The Gatekeeper 1
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.
Cisco IOS
In Cisco IOS, the dot1x system-auth-control command enables 802.1X for the whole switch (Listing 1).
radius-server host Radius IP adds the RADIUS server, and key defines the RADIUS secret. The aaa
authentication assigns the radius group. The dot1x pae authenticator and dot1x port-control auto commands
convert the selected interface into a 802.1X interface. The guest VLAN, which sends the client to a
non-critical network in case authorization fails, is configured by dot1x guest-vlan vlan-id. For more details,
check out the IOS Configuration Guide [3] or the FreeRADIUS wiki [4].
The Gatekeeper 2
Listing 1: Configuring Cisco IOS
01 Switch# configure terminal
02 Switch(config)# dot1x system-auth-control
03 Switch(config)# aaa new-model
04 Switch(config)# aaa authentication dot1x default radius
05 Switch(config)# radius-server host 192.168.123.23 auth-port 1812 key hEoLw6DC
06 Switch(config)# interface fa1/10
07 Switch(config-if)# switchport mode access
08 Switch(config-if)# dot1x pae authenticator
09 Switch(config-if)# dot1x port-control auto
10 Switch(config-if)# end
11 Switch# show dot1x interface fa1/10 details
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.
Listing 2: Excerpt from ca.cnf
01 [certificate_authority]
The Gatekeeper 3
02 countryName = DE
03 stateOrProvinceName = Hamburg
04 localityName = Hamburg
05 organizationName = UebelHacker
06 emailAddress = ca@uebelhacker.de
07 commonName = "UebelHacker CA"
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
01 [server]
02 countryName = DE
03 stateOrProvinceName = Hamburg
04 localityName = Hamburg
05 organizationName = UebelHacker
06 emailAddress = radius@uebelhacker.de
07 commonName = "UebelHacker Radius Server"
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 Makef
01 client.crt: client.csr ca.pem ca.key index.txt serial
02 openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(CAPWD) -out clie
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.
The Gatekeeper 4
Listing 5: User Database
01 dau Auth-Type := Reject
02
03 DEFAULT Auth-Type := EAP, Login-Time := "Wk0800-2000"
04 Tunnel-Type = 13,
05 Tunnel-Medium = 6,
06 Tunnel-Private-Group-Id = 23,
07 Fall-Through = Yes
08
09 uebelacker Auth-Type := EAP, Login-Time = "Any"
10 Tunnel-Private-Group-Id = 42
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).
The Gatekeeper 5
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.
Listing 6: xsupplicant.conf
01 default_netname = intranet
02 intranet {
03 type = wired
04 allow_types = eap_tls
05 identity = uebelacker
06 eap_tls {
07 user_cert = "/path/to/s@uebelhacker.de.pem"
08 user_key = "/path/to/s@uebelhacker.de.pem"
09 user_key_pass = "Usercert-Passwort"
10 root_cert = "/path/to/ca.pem"
11 chunk_size = 1398
12 random_file = /dev/urandom
13 }
The Gatekeeper 6
14 }
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.
Listing 7: wired.conf
01 eapol_version=2
02 ap_scan=0
03 fast_reauth=1
04 network={
05 key_mgmt=IEEE8021X
06 eap=TLS
07 identity="uebelacker"
08 ca_cert="/path/to/ca.pem"
09 client_cert="/path/to/s@uebelhacker.de.pem"
10 private_key="/path/to/s@uebelhacker.de.pem"
11 private_key_passwd="Usercert-Passwort"
12 eapol_flags=0
13 }
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.
Listing 8: Interfaces Enables DHCP
01 auto eth0
02 iface eth0 inet dhcp
03 wpa-iface eth0
04 wpa-driver wired
05 wpa-conf /etc/wpa_supplicant/wired.conf
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.
The Gatekeeper 7
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.
INFO
[1] IEEE 802.1x-2004: http://www.ieee802.org/1/pages/802.1x-2004.html
[2] RFC 5216, "EAP-TLS Authentication Protocol": http://tools.ietf.org/rfc/rfc5216.txt
[3] Cisco 802.1x Guide:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sg/configuration/guide/dot1x.html
[4] FreeRADIUS Wiki on Cisco IOS commands: http://wiki.freeradius.org/Cisco
[5] FreeRADIUS Project: http://freeradius.org
[6] FreeRADIUS at GitHub: http://github.com/Antti/freeradius-server/tree/master
[7] OpenSEA: http://openseaalliance.org
[8] Open1X project: http://open1x.sf.net
[9] WPA supplicant: http://hostap.epitest.fi/wpa_supplicant/
[10] Tiny CA: http://tinyca.sm-zone.net
[11] EAP-IKEv2 project on Sourceforge: http://eap-ikev2.sf.net
[12] EAP modes supported by FreeRADIUS: http://freeradius.org/features/eap.html
The Gatekeeper 8


Wyszukiwarka