Configuring LAN edge switches for network access authentication

Edge switches are an important part of in-depth network defense, essential to protecting edge nodes from each other and able to decrease the low-end workload on security devices deeper in the network so they can focus on higher-level threats.

Of all the unused security features lying dormant on intelligent edge switches in LAN data closets, perhaps the single most important one for improving LAN security is authenticated network access.

In the data center, IT has complete control over who can plug something into the network and who can have physical access to a device on the network. Outside the data center, that's not the case. In the LAN, that's where authenticated network access comes in. It ensures that users provide credentials at the switch in order to talk to anything beyond on the network.

How switch-based network access authentication works

The IEEE 802.1X standard governs the authenticated access, and both wired and wireless networks can require 802.1X authentication before providing access. The standard defines traffic among three entities: the supplicant, the authenticator, and the authentication server.

The supplicant is the computer (or other device) trying to connect through the authenticator -- the switch or access point. They communicate using the Extensible Access Protocol (EAP). The switch or access point uses the Remote Authentication Dial-In User Service (RADIUS) protocol to send credentials to the authentication server (AS), which checks them and sends back either a success or a failure, accepting or denying the supplicant.

Choosing the right RADIUS servers and readying them for 802.1X and EAP

For authenticated network access to work, the network needs a RADIUS server that supports EAP. Enabling the Network Policy Server on a Windows server (Internet Authentication Service, prior to Windows 2008) provides the service in a Windows domain. Lots of other RADIUS servers are available from network vendors, including Alcatel-Lucent, Cisco and Juniper. Freeware is also available. The key to long-term manageability is making sure your RADIUS service is connected to your domain authentication service (be it Active Directory, Lightweight Directory Access Protocol, or something else) and that it doesn't maintain a separate set of credentials.

To make the RADIUS server 802.1X-ready, an admin must set up a key and get a digital certificate. (This may have been done in support of some other security appliance, such as a VPN concentrator.) Any OpenSSL client or Windows IIS server can request a certificate with the right attributes in place. The most secure systems use EAP-TTLS or PEAP, which require certificates on client machines too, but this is optional. This is not required with EAP-TTLS.

Also, supplicants must support EAP and gracefully handle the transition from the un-trusted state (black hole VLAN  and address) to the trusted state (usable IP address and VLAN). Some older desktop operating systems did not do well with this, but even Windows XP (post service pack 1) is sufficient.

Enabling LAN switch security

The next step is to enable security on the switches. Methods vary by switch vendor but should look something like this (with actual IP addresses substituted):

radius server host 192.168.001.001 key RadiusServersEncryptionKey
aaa authentication dot1x default radius
dot1x system-auth-control
interface Ethernet g2-g48 dot1x port-control auto

That is:

•  Tell the switch what RADIUS server to talk to.
• Tell it to use RADIUS authentication with 802.1X.
• Tell it to turn on 802.1X.
• Tell it to require 802.1X on ports g2 through g48.

Many variations are possible; for example, one might want to have a VLAN on which authentication is not required but which allows access to the Internet only and not to the rest of the corporate LAN:

interface Ethernet g2-g48 dot1x port-control auto unauth-vlan 13

Specifying network access authentication for specified user groups

The choice of whether to require network authentication, and what to do with unauthenticated access attempts, has to be driven by careful consideration of user populations and can be sanctioned for specific user groups or scenarios. An organization may want to grant mobile, temporary Internet access without credentials to user populations such as consultants or professional services staff while not wanting to grant data center access. That same organization might want to require authentication for any access by a user plugging into a regular office's network jack on the assumption that only company staff should be using those for access.