The New Face of Authentication

The standard uses EAP (Extensible Authentication Protocol) and its algorithms for exchanging messages during the authentication process. Among the algorithms EAP (RFC 2284) supports are MD5 (Message Digest 5), TLS (Transport Layer Security), TTLS (Tunneled TLS), LEAP (Lightweight EAP) and PEAP (Protected EAP) (see "The Alphabet Soup of Authentication,", for more on these protocols).

But 802.1x is no silver bullet for ensuring users are who they say they are. It requires digital-certificate management, which is complex, and the 802.1x client and server software must be compatible with one another. It's not yet plug and play, either, because its authentication algorithms are still immature.

Architecturally Speaking

The 802.1x protocol consists of three main elements. The supplicant is a client device, such as a desktop, laptop or PDA, that requires secure network access. Then there's the authenticator, which can be an intermediary device, such as a wireless access point or a network switch. It exchanges information between the supplicant and the authentication server, the third piece of 802.1x. The authentication server can be a RADIUS server that authenticates users with its own user database or by working with an external user database, such as Microsoft's Active Directory or another LDAP database.

RADIUS servers are a popular choice for the 802.1x authentication server because most enterprises use them for secure dial-in user access. With a RADIUS server, you can avoid storing user information on each access point or network switch. It's also helpful for redundancy purposes, where a backup RADIUS server can take over the authentication process if the primary server fails. RADIUS supports most of the commonly used EAP authentication mechanisms, such as TLS, TTLS, LEAP, MD5 and PEAP.For a SOHO wireless environment where it's not feasible to set up a RADIUS server for 802.1x, an administrator at the office or a user working from home can use a preshared key entered manually on both the client and access points. The access point then creates a WEP key and sends it to the wireless client, encrypting it with the preshared key.

All Wired

Organizations deploying 802.1x can authenticate their users to the LAN with a user name-password combination or stronger authentication. 802.1x authentication is widely available from big-name switch vendors, including Alcatel, Cisco Systems, Enterasys Networks, Extreme Networks and Foundry Networks. When a switch--the authenticator--detects an active client at the other end of the link in an 802.1x-enabled port, it initiates the 802.1x authentication process.

We recently tested 802.1x security on a wired Ethernet LAN in Network Computing's Real-World Labs® at Syracuse University. A Foundry Networks FastIron 4802 switch was the 802.1x authenticator, and the authentication server was a Microsoft Windows 2000 Advanced Server with Internet Authentication Services (IAS). On the IAS server, we registered the Foundry switch as a client device and set the remote-access policy to allow network access only during normal business hours.

We used MD5 as our authentication algorithm. MD5 uses a one-way hash function with the shared key and challenge to verify the supplicant's credentials, and it's the simplest one to use in the 802.1x world. However, it's not typically the algorithm of choice on the wireless side because it supports only client authentication, which leaves it vulnerable to rogue wireless APs (access points).802.1x is disabled by default on all switch ports. So we used the Foundry switch's command-line interface to configure it for 802.1x authentication on the ports supporting 802.1x clients.

We also activated the 802.1x feature on the Windows XP client, which meant changing the 802.1x setting on the Foundry switch to the auto mode. That lets users authenticate with 802.1x after the Windows XP client with EAP-MD5 connects to the port. Then 802.1x prompts you to enter your user name and password to reach the network. In all, our lab test demonstrated that wired 802.1x is easy to deploy and configure, and that it works well with existing security solutions such as ACLs (access-control lists) and VLANs (virtual LANs)Although 802.1x is still rare in wired networks, it plays a major role in authenticating users in wireless networks. Cisco has LEAP, its proprietary implementation of EAP authentication for wireless LANs and based on a strong challenge-password hash exchange rather than certificates. Cisco's Access Control Server supports LEAP, as does Funk Software's Odyssey solution and Steel-Belted RADIUS server.

With LEAP, the RADIUS server sends a challenge to the client, which then sends back a one-way hash of the user password. The RADIUS server then compares the client response to its own. LEAP provides mutual authentication: The client as well as the AP authenticate one another. Then the client and AP get the dynamic WEP key.

We tested wireless 802.1x and LEAP with an Aironet 350 series card, Cisco 1200 series access point and Funk's Steel-Belted RADIUS server. To configure LEAP in the Cisco 1200, we had to specify the port the RADIUS server would use as well as the key the two devices shared. We also had to enable the EAP option.

The RADIUS server, meanwhile, required that the Cisco AP be added as a client. We also had to specify the shared RADIUS key and the users needing authentication. To enable LEAP for the users, we modified the "eap.ini" file of the RADIUS server.On the client, we selected the LEAP security option and entered the correct user name and password to securely connect to the network. LEAP is relatively easy to configure compared with some other complex authentication mechanisms that use certificates.

To test the EAP-TLS piece of 802.1x, we used a Windows 2000 Advanced Server running Microsoft's Internet Authentication Service for RADIUS authentication and Active Directory for the user database. EAP-TLS uses digital certificates for mutual authentication, so we tapped our existing certificate-authority infrastructure in the Syracuse lab. If you don't have a CA in place, you can get certificates from VeriSign or another a third-party vendor. The trade-off with digital certificates is that they can incur overhead because you have to issue, manage and then revoke a certificate if it's necessary to block a user's access. But since certificates are more secure than passwords, they're worth a little extra work.

With this setup, the RADIUS server sends its digital certificate to the XP client. The client then checks the issuer of the certificate and its contents, and then sends its own certificate to the RADIUS server. The RADIUS server performs the same verification procedure, verifying the issuer and contents of the certificate. In the end, the client receives a successful authentication message, and the client and server get the dynamic key.

Taking the LEAP

Cisco, meanwhile, isn't banking completely on LEAP as its authentication method. Along with Microsoft and RSA Security, Cisco has developed PEAP, an open standard. It's already available commercially: Cisco has PEAP built into its client, and Funk's Odyssey client 2.0 also supports it. Microsoft's Windows XP with SP1 or above includes support for PEAP, and Microsoft offers a free download of the 802.1x authentication client with PEAP for Windows 2000. You can get 802.1x clients for Windows 98 and NT 4.0 through Microsoft's Premier and Alliance support contracts.We also tested PEAP for 802.1x using a Windows XP client and a Windows 2000 Advanced Server-based RADIUS server. The Windows XP client with SP1 supports PEAP with the MS-CHAPv2 algorithm, which is password-based and uses a combination of MD4, SHA-1 (Secure Hash Algorithm) and DES (Data Encryption Standard) algorithms. You must enable EAP authentication when MS-CHAPv2 support is active. The TLS channel then encrypts the entire exchange procedure, and the RADIUS server and client exchange MS-CHAPv2 challenge request/responses to authenticate one another. If you use EAP-TLS with PEAP in your 802.1x implementation, both your server and client will need certificates, making it a more complex but stronger implementation than PEAP with EAP-MS-CHAPv2.

TTLS, developed by Funk and Certicom Corp., meanwhile, is an extension of TLS that eliminates the need for client-side certificates. TTLS clients are available for Linux, Mac OS X, Windows 95/98/Me/ 2000/NT/XP and Pocket PC OSs. We ran Funk's TTLS-based Odyssey server on a Windows 2000 Advanced Server, a Cisco 1200 series AP and a Windows 2000 laptop with the Odyssey client 2.0. We created a certificate authority using the Odyssey tools. It was easy to configure the Odyssey server: We added the access point and specified the users in the database plus a few RADIUS settings. The Odyssey client lets you select the authentication mechanism and the inner authentication protocol for TTLS.

X Games

The 802.1x standard will be a big part of the upcoming wireless security 802.11i specification, with its strong authentication and key distribution and rotation approach. With the 802.11i standard awaiting final approval, the Wi-Fi Alliance came up with an interim security standard, Wi-Fi Protected Access (WPA), that also uses the 802.1x framework for authentication. It requires a simple firmware update for the wireless devices, plus it's compatible with the upcoming 802.11i standard.

On the wired side, most users working from home use VPN sessions to reach the corporate network. VPNs and 802.1x are a good combination: With 802.1x, firewalls and IPsec-based VPN security are more effective against targeted attacks. Although 802.1x still faces stiff competition from well-entrenched third-party vendor security products such as Bluesocket and ReefEdge, it just may emerge as the safest and simplest way for users to securely access network resources.Dilip Advani is a research associate at Syracuse University's Center for Emerging Network Technologies. He has worked as a network engineer and a telecommunications consultant. Write to him at [email protected].

Post a comment or question on this story.

If you're taking the leap into 802.1x authentication, beware: The options can be overwhelming. There's LEAP, PEAP, TLS and TTLS, among others. So which protocol does what?

LEAP is Cisco's proprietary version of EAP (Extensible Authentication Protocol), and it uses strong challenge-password hash exchange instead of digital certificates. But Cisco has hedged its bets and joined forces with Microsoft and RSA Security to develop PEAP (Protected EAP), best known for helping prevent an attacker from injecting his or her own data or capturing clear-text user information for future attacks during the 802.1x EAP authentication process.

PEAP works in two steps. After the initial handshake between the client and access point, a TLS (Transport Layer Security) channel is created between the client and authentication server. All messages get encrypted, and the RADIUS server then authenticates the client using an EAP method--EAP-TLS or EAP-MS-CHAP (Challenge Handshake Authentication Protocol) v2.

With TTLS (Tunneled Transport Layer Security), a TLS tunnel is established and the client authentication parameters get exchanged. TLS has existed longer than TTLS, but its usage has waned because it requires extra certificates on each client.TTLS and PEAP are similar in concept, but there are important differences: TTLS supports other EAP authentication methods and also PAP, CHAP, MS-CHAP and MS-CHAPv2, whereas PEAP can tunnel only EAP-type protocols such as EAP-TLS, EAP-MS-CHAPv2 and EAP-SIM. TTLS requires installation of client software, whereas PEAP comes ready to run in XP Service Pack 1 on the client device, for instance. TTLS is widely available and implemented, while PEAP is still new. But given PEAP's backing from Cisco, Microsoft and RSA, it's likely to emerge as the de facto authentication mechanism for 802.1x.