Vendors hit the 802.1X mark for access, but security holes remain

802.1X is maturing, but it will take a skilled network technician to configure it in products across any large deployment.

While previous iLabs security-based testing focused strictly on how the IEEE 802.1X authentication standard helped lock down wireless LAN connections, this year’s testing also spanned the wired world.

The protocol has matured and vendors have expended a great deal of effort into building products – which in this test include client-side software, wireless access points, wired switches  and authentication servers – around this standard. However, this year’s testing demonstrates that some offerings based on 802.1X still have a ways to go before we could recommend them as enterprise-class security products.

See also:

iLabs introduction

SIP aces basic interop tests

Team mixes MPLS and IPv6 for enterprising results

The products do implement 802.1X, but in most cases it’s going to take a very skilled network technician to configure 802.1X products across any large deployment. It also seems that attention to implementing 802.1X has distracted vendors for hitting on other security standards such as in digital certificate processing, management  interface security and event logging. These non-802.1X issues could affect 802.1X deployment overall.

Where to begin?

In the 802.1X world, a client is referred to as a supplicant. The device it connects to is an authenticator. Behind the authenticator is an authentication server that maintains a client/server relationship with the authenticator.

We used supplicant software running on PCs and Macintosh machines connecting to wireless access points or wired switches, with RADIUS servers providing authentication. The supplicants tested were from Cisco, Funk Software, Meetinghouse Communications, Microsoft and the open source implementation Open1x. Wireless gear vendors represented were Broadcom, Cisco, Extreme Networks, Proxim, Symbol Technologies and Trapeze Networks. Participating wired switch vendors included Cisco, Extreme and HP . Stepping up with 802.1X-compliant RADIUS implementations were Cisco, Infoblox, Funk, Meetinghouse, Microsoft, Radiator, Roving Planet and open source FreeRADIUS.

In last year’s testing, we examined the various protocol options for authentication including Protected Extensible Authentication Protocol (PEAP) and Tunneled Transport Layer Security (TTLS), which use server certificates, and TLS, which uses client and server certificates (see here ).

This year we focused on testing typical combinations of the three components (supplicant, authenticator and authentication server) to determine if the various components could authenticate correctly, connect to the network and display a Web page running on a test server.

We concluded that the basic interoperability battles were over. Vendors now are shipping 802.1X-capable devices, in both the wireless and wired cases. Most implementations were able to simply plug in and interoperate. There were certainly some bugs uncovered, such as problems with digital certificates, and problems connecting certain authenticators (switches) to some RADIUS servers, but no more than you’d find in any other new set of products that were thrown together.

Tell me again why I would care now?

We’ve been reporting on 802.1X as an emerging security technology for three years. But we’re arguing that network professionals should pay attention now because:

•  Wireless access control. With 802.1X in its current state, we finally are seeing the standards process offer a set of technically sound, secure access control mechanisms. This will continue to improve the options available to control and secure wireless (and wired) networks.

•  Strong cryptography standards. 802.1X is part of the IEEE’s ongoing activities to make sure that networks can be secured. As 802.11i – which specifies a safer keying mechanism with Temporal Key Integrity Protocol (TKIP) to replace Wired Equivalent Privacy (WEP), and use of Advanced Encryption Standard (AES ) for encryption – becomes available, we will finally be able to have authenticated networks that use generally accepted strong cryptographic algorithms.

•  Fine grained LAN access control. The deployment of 802.1X will lay the groundwork for future security mechanisms – like being able to stop denial-of-service  attacks by blocking network access, or limiting network access to properly scanned workstations – to control network access on a user-by-user and port-by-port basis. This will mean that in the near future you will be able to better manage network repairs if you have virus or worm outbreaks and have to shut off selected sections of your network.

That said, we’ve pinpointed several issues that can complicate the use of 802.1X, including ease of use, end-user mobility and component compatibility within the client machine.

Ease of use issues arising around 802.1X implementations exhibit the same class of problems we’ve encountered with technologies such as IPSec in the past. Adding 802.1X support to your network means you have a new set of complex user interface screens with user-unfriendly terms such as TKIP and TTLS. Few, if any, supplicant vendors have made the user interface easy.

Microsoft’s supplicant uses multiple windows buried behind the “Network Connections” control panel to configure 802.1X. Cisco’s supplicant uses its own multi-screen user interface and then still requires you to configure the Microsoft supplicant on top of it. Additionally, most of the supplicants don’t support diagnostic logging, making troubleshooting difficult. Together, these things can mean high deployment costs.

Mobile users of laptop computers or wireless handheld devices will want to travel between 802.1X domains. However, you have to be careful to configure the 802.1X supplicant software to allow this. Some implementations disable by default those portions of the Microsoft driver components so that you can no longer access an open wireless access point like you find at many Wi-Fi hot spots. This rigidity won’t work if you have users who take their notebook computers from the office where they use a 802.1X-enabled wireless access point to coffee shops or other environments that typically don’t use 802.1x. In this example, those users would be denied access the Internet.

The 802.1X supplicant introduces yet another link-layer protocol processing component into client machines. This is an area where the technology is complex and delicate and errors occur when technologies are mixed. Combining 802.1X supplicants, virus scanning, personal firewalls, and VPN client software into one end user machine can be a daunting debugging task.

What is missing?

All supplicants and all authentication servers that implement 802.1X are part of the network infrastructure, use cryptography and play a role in the overall authentication scheme. Therefore, there are generally accepted security considerations that these products should address. As part of the infrastructure, they should have features that implement resiliency, such as the ability for an access point to use alternative RADIUS servers in case the primary server fails. This sort of resiliency is missing in some of the products. Because the RADIUS server is a critical part of the authentication mechanism, a failure there will stop access.

All RADIUS servers implementing 802.1X must have a server certificate. This means they have to implement the same level of security for storing cryptographic keys as other devices, such as Secure Sockets Layer (SSL )-enabled Web servers. Many vendors don’t do this. Instead, they simply store the RSA Private Key, used in the SSL protocol, in an unencrypted file on the local hard disk. HP’s switches, for example, do not store the private key in an encrypted fashion. Lax processing of the certificates means that an attacker could obtain a client 802.1X certificate, install it in a RADIUS server and masquerade as a legitimate server, thus tapping network traffic.

Like any other network infrastructure devices, wireless access points, switches and RADIUS servers should have securable management interfaces. This usually means the use of Secure Shell (SSH), if they have a console interface, or SSL (Secure-HTTP) if they have a Web interface. Cisco’s access points do not do this – you can only manage them with an unencrypted connection to their Web interface. Neither does Meetinghouse. Infoblox gets partial credit – it uses SSL for its Web user interface but it only supports self-signed certificates. This means that an attacker who can gain access to the network used for device management potentially could sniff passwords. Even with a self-signed certificate, a man-in-the-middle attack still could be used to gain management access. Other vendors, such as Trapeze and Extreme, provide SSH and SSL management interfaces.

Finally, there should be a reasonable mechanism for these devices to share their event logs with a centralized security event management system so that the network managers can monitor attempted attacks or intrusions and create security audit trails. Neither Cisco nor Funk offer external logging from their RADIUS servers. Other implementations, such as Infoblox, Microsoft and Roving Planet, provide integration with an external logging facility.

Where is 802.1X going?

The standards still are moving. Just last month, Cisco proposed, and then unilaterally deployed, yet another authentication mechanism called Extended Authentication Protocol – Flexible Authentication via Secure Tunneling (EAP-FAST). EAP-FAST addresses Cisco’s concern that users don’t want to use certificates and would prefer to use passwords for authentication. Cisco has asked the IETF to accept EAP-FAST as an Informational (not a standard) RFC. It applies to the wireless and wired environments.

Another area to be addressed is the consistent use of 802.1X in the wired case. If you have made the policy decision that access to your wired network should be controlled, you need to be consistent about that or you will introduce security holes. The only 802.1X-capable supplicants shown in the iLabs demonstration are workstations. Even the wireless access points, which are themselves clients if you think about the cable coming out of the back and going into a switch, should be capable of using 802.1X as a supplicant.

A network deployment with 90 workstations all using 802.1X authentication doesn’t protect the LAN if the printer and the UPS aren’t also using it or aren’t otherwise protected. If your security policy is such that all network access must be authenticated, you don’t want to leave unlocked doors, whereby an attacker can get on the network simply by unplugging a printer and plugging in a computer to launch an attack.

All vendors of network-enabled devices should offer 802.1X if this is going to be deployable in a secure consistent manner. This same concern also applies as more specialized, network enabled handheld devices go wireless.