IEEE 802.1X is a very cool security feature. It was developed to provide real security for wired and wireless networks at layer two. A client connected to an 802.1X-protected port can't send any traffic other than EAP to the switch until he successfully authenticates with the proper credentials or certificate. This article demonstrates how you can setup a simple 802.1X lab using a Windows XP-based client and RADIUS server.

802.1X Operation

A network switch acts as the middleman between an authenticating client and an authentication server. The switch implements two protocols: EAP is used to communicate with the client at the network perimeter, while RADIUS is used to relay authentication details to the server inside the network. EAP offers a number of authentication mechanisms, but our setup will use simple username/password authentication with an MD5 challenge. The flow of a successful authentication is illustrated here:

For a better idea of what this exchange looks like on the wire, check out these packet captures of 802.1X and RADIUS traffic.

Server Configuration

For my setup, I chose to install FreeRADIUS on my Gentoo Linux workstation, but any RADIUS service should work. The configurations in this section correspond to a bare FreeRADIUS deployment using cleartext credentials stored in a text file. Obviously, real-world deployments would dictate a much more robust and secure authentication method such as LDAP.

The base server configuration is located in radiusd.conf (on Linux, this file should reside in /etc/raddb/), but we shouldn't need to change any of the default values for this lab. However, we will need to add the subnet address from which we expect to receive authentication requests (10.0.0.0/24) in clients.conf. Remember that although the 802.1X client resides in VLAN 10, the RADIUS client (the switch) will be sending requests from its 10.0.0.1 interface. Copy and paste this block to enable the network with the shared secret of MyRadiusKey:

client 10.0.0.0/24 {
    secret      = MyRadiusKey
    shortname   = Lab
}

We'll also define a user/password combination for testing. I've created the user John.McGuirk with the password S0cc3r. Feel free to pick your own username and password, but make sure to maintain the spacing in the configuration file (the reply message is optional):

John.McGuirk    Cleartext-Password := "S0cc3r"
                Reply-Message = "Hello, %u"

After completing this configuration remember to (re)start the RADIUS service.

Switch Configuration

Port-based 802.1X authentication allows for some really cool security measures (like dynamic VLAN assignment and per-user ACLs), but for this lab we'll establish a base configuration just for demonstration's sake.

A preliminary step, if you haven't done so already, is to enable IP routing on the switch:

Switch(config)# ip routing

Before diving into the actual 802.1X configuration, we'll need to enable Authentication, Authorization, and Accounting (AAA) for the switch (this step can be skipped if AAA is already active). A word of caution: enabling AAA changes the authentication method used by the VTY (telnet) lines to fit the AAA model. It's a good idea to define a local username and password to authenticate to the switch if you haven't done so (this account is unrelated to our 802.1X configuration, just a way for us to log in again if we need to).

Switch(config)# aaa new-model
Switch(config)# username admin secret MyPassword

Next we'll configure the switch with the address and shared key of our RADIUS server. By default, Cisco switches will use UDP port 1645 for RADIUS authentication and port 1646 for accounting. Depending on the RADIUS daemon you chose to implement, you may need to modify these ports to match those used by your RADIUS daemon. FreeRADIUS, for example, uses the more recent port specification defined in RFC 2138, and requires additional configuration on the switch to reflect the port changes:

Switch(config)# radius-server host 10.0.0.100 auth-port 1812 acct-port 1813 key
 MyRadiusKey

Now we'll tie these two components together by configuring AAA to reference the RADIUS server for 802.1X authentication requests:

Switch(config)# aaa authentication dot1x default group radius

This takes care of the RADIUS portion of the configuration. Configuring 802.1X from this point is simple: enable it globally for the switch, and individually per interface:

Switch(config)# dot1x system-auth-control
Switch(config)# interface g0/12
Switch(config-if)# switchport mode access
Switch(config-if)# dot1x port-control auto

Note that the interface must be set to static access mode. If left in dynamic mode (where DTP is used to negotiate the port's function as either access or trunking), the switch will issue an error message stating that 802.1X cannot be configured on dynamic ports.

If you're inquisitive like me and issue a question mark to invoke the context-sensitive help in the midst of issuing a new command, you might have noticed that the dot1x port-control interface command has three options. These are:

• auto - Normal 802.1X authentication
• force-authorized - No 802.1X authentication is used (this is the default setting, to prevent service interruption while deploying 802.1X)
• force-unauthorized - Ignores authentication attempts, port is always unauthorized

You can use the show dot1x command to verify the configuration of your client-facing interface:

Switch# show dot1x interface g0/12
Supplicant MAC <Not Applicable>
   AuthSM State      = N/A
   BendSM State      = N/A
PortStatus        = N/A
MaxReq            = 2
MaxAuthReq        = 2
HostMode          = Single
PortControl       = Auto
QuietPeriod       = 60 Seconds
Re-authentication = Disabled
ReAuthPeriod      = 3600 Seconds
ServerTimeout     = 30 Seconds
SuppTimeout       = 30 Seconds
TxPeriod          = 30 Seconds
Guest-Vlan        = 0

Client Configuration

The last element to configure is the supplicant software on the client. If your client is currently connected, unplug it temporarily before continuing (reconnecting after the configuration has been completed will make it easier to observe the 802.1X behavior). For my lab, I used a Windows XP box with SP2.

To enable the Windows 802.1X service, open Services from the control panel, and select and start the Wireless Zero Configuration service. ("But isn't this a wired connection?" I hear you ask. Thank you, Microsoft.) (Edit: Wired 802.1X is enabled by a separate service, Wired AutoConfig, in XP SP3. Thanks to Dude for pointing this out!) Next, open Network Connections from the control panel and open the Connection Properties dialog for the adapter you're using. You should have an Authentication tab within this window; if not, the 802.1X service isn't running and you'll need to do some troubleshooting.

Enable 802.1X authentication and set the EAP type to MD5-Challenge. This will allow us to use basic username/password credentials instead of a more secure (and much more complex) PKI scheme. You can safely deselect the "authenticate as computer" and "authenticate as guest" options.

Authenticating

If everything is configured correctly, you should now be able to authenticate via 802.1X. Verify your IP addressing and connect your client to the switch. After roughly thirty seconds you should be prompted for authentication credentials by a little balloon. (In a more ideal setup, your Windows credentials and/or a client certificate would be sent without your interaction and 802.1X authentication would occur transparently.) Your prompt may differ from the example shown here.

Enter the username and password you configured on the RADIUS server in the authentication dialog.

Your client will notify you after a bit if the authentication fails. If you receive no notification, authentication has succeeded and you should be able to send traffic through the switch port (try pinging through to the RADIUS server to verify this). Issue the show dot1x command on the switch again to verify that the port is now in the "authorized" state.

Switch# show dot1x interface g0/12
Supplicant MAC 0014.22e9.545e
   AuthSM State      = AUTHENTICATED
   BendSM State      = IDLE
PortStatus        = AUTHORIZED
MaxReq            = 2
MaxAuthReq        = 2
HostMode          = Single
PortControl       = Auto
QuietPeriod       = 60 Seconds
Re-authentication = Disabled
ReAuthPeriod      = 3600 Seconds
ServerTimeout     = 30 Seconds
SuppTimeout       = 30 Seconds
TxPeriod          = 30 Seconds
Guest-Vlan        = 0

One other detail to note: Initially, the client's port on the switch will only transition to up/down (interface up, line protocol down) when you first connect. Only after successfully authenticating via 802.1X will it transition fully to up/up.

If authentication fails for some reason you'll have to do some sleuthing to determine the cause. Keep the following tips in mind:

• Ensure that the switch is trying to authenticate to the correct RADIUS server on the correct UDP port
• Ensure the RADIUS server is configured to accept authentication requests from the correct subnet
• Review the RADIUS daemon logs for messages concerning failed authentication or misconfiguration
• Use a variation of the debug dot1x command on the switch or a packet sniffer to verify EAP and RADIUS traffic
• Try using the free NTRadPing RADIUS Test Utility to independently verify operation of the RADIUS server