Strategy: Wireless security with 802.1X

Network professionals in search of technology that melds authentication, encryption and wireless LANs will find the IEEE 802.1X specification is up to the job.

As a Layer 2 authentication protocol, 802.1X doesn't let anyone on the network until they've been properly authenticated. With built-in hooks for setting wireless encryption keys, 802.1X also solves the worst problems of wired equivalent privacy (WEP): avoiding well-known, widely distributed keys. The only problem with 802.1X is that it is an emerging technology that requires upgrades to authentication servers, client software on all PCs, and appropriate configuration in the wireless access points.

New products supporting 802.1X have popped up rapidly, and iLabs comprises the largest-ever public demonstration of 802.1X. Since the last round of iLabs testing in May, the team has added a new authentication server (Aegis, from Meetinghouse Data Communications), a Mac OS X 802.1X client (also from Meetinghouse), and prototype Protected Extensible Authentication Protocol (PEAP) support in Windows XP client and Cisco's ACS authentication server, to its secure wireless deployment.

PEAP and Tunneled Transport Layer Security (TTLS) are two proposals that add support for legacy authentication mechanisms like username/password and token cards to the 802.1X spec. However, neither has reached standards status. The Internet Engineering Task Force (IETF) requires that any standardized protocol be proven to work, and having multiple interoperable implementations is a critical step along that path. TTLS offers support for a wider range of legacy authentication methods and was implemented first, so it should win favor among network managers. However, RSA Security, Microsoft and Cisco proposed PEAP. While company affiliation isn't supposed to be important within the IETF process, proposals brought in by these networking powerhouses are generally taken very seriously.

We tested different authentication methods to see how well we could mix and match products in the iLabs network. MD5, the simplest authentication method in the 802.1X world, worked pretty well. Some wireless access points, such as those produced by Symbol, don't support MD5. This is actually a good thing - MD5 is not appropriate for wireless 802.1X authentication, because it does not set up WEP keys.

When we moved onto TLS using digital certificates, the only authentication server that had trouble supporting this method was Microsoft.

We tried to use TLS authentication with a beta version of .Net Server. We found it easy to set up the .Net 802.1X authentication server, but for MD5 authentication only. When we tried to move to TLS authentication, using digital certificates, the .Net Server would not recognize our Netscape certificate authority. Microsoft assumes a total Microsoft implementation, using multiple servers, Active Directory and the Microsoft certificate authority, which wasn't the interoperability demonstration we sought.

Despite the .Net Server setback, we concentrated our testing on the 802.1X servers, adding two new products (from Cisco and Meetinghouse) to the list and retesting servers from Funk Software, Hewlett-Packard, Microsoft and Secure Computing.

The results are encouraging. Although we are dealing with new products and beta code, we've worked with the vendor development teams to get things to work. For example, Wind River, the OEM behind many popular access points, debugged and modified its software to pass PEAP properly after discovering an incompatibility during PEAP testing.

More N+I Atlanta 2002 iLabs coverage

Strategy: Wireless security with 802.1X

Related Links