Insecurity has been the dirty little secret holding back wireless technology in large enterprise networks.
The 3-year-old Wired Equivalent Privacy (WEP) protocol has been discredited so thoroughly that its authentication and encryption capabilities are not considered sufficient for use in enterprise networks. In response to the WEP fiasco, many wireless LAN vendors have latched onto IEEE 802.1x standard to help authenticate and secure both wireless and wired LANs. The wildcard with 802.1x protocol is interoperability.
In our testing, which accounts for the first public 802.1x interoperability event, we evaluated how well the various pieces of a wireless network work together according to this security specification. All told, we tested five 802.1x supplicants (client-side software) from Cisco Systems Inc., Funk Software Inc., Hewlett-Packard Co., Meetinghouse Data Communications Inc. and Microsoft Corp.; six 802.11b wireless access points from 3Com Corp., Cisco, Enterasys Networks Inc., Karlnet Inc., Symbol Technologies Inc. and Wind River Systems Inc.; two 802.1x wired switches from Cisco and HP acting as authenticators, and five Remote Authentication Dial-in User Service (RADIUS) based authentication servers handling the 802.1x queries from Funk, HP, Interlink Electronics Inc., Microsoft and Secure Computing Corp.
Overall, we found that while 802.1x design and configuration is complicated on the front end, once the network is up and running, interoperability between supplicants and authentication servers is pretty good. The major limitations come in the area of authentication methods supported and in platform support for different operating systems and authentication databases.
This iLabs testing is not intended to be a comprehensive interoperability test encompassing all the 802.1x wireless products on the market. But with the amount of testing we did complete, you can glean quite a bit of wireless network deployment advice.
Cooking Up an 802.1x Net
Any 802.1x deployment requires five components. Supplicant software runs on the device needing authentication. An 802.1x-compatible network adapter also is required on the client. That sounds simple, but while most supplicants work with most network adapters, it’s not a given by any means.
The supplicant needs to talk to an authenticator, such as a wireless access point or an 802.1x-enabled LAN switch.
The authentication is handled by an authentication server, normally a RADIUS server that has been extended to support the Extensible Authentication Protocol (EAP). Technically, it doesn’t have to be a RADIUS server and even can be built in to the wireless access point on the low end. But any enterprise sized wireless deployment is going to have a RADIUS server as part of the picture because it centralizes authentication and it scales well.
Finally, the authentication server has to talk to a user database. This could be a list of users and passwords, an Lightweight Directory Access Protocol (LDAP)-based directory or SQL database, or digital certificates issued by a public-key infrastructure (PKI).
In building the 802.1x test bed, you have to get the right mix because not every piece supports every option. Some RADIUS servers do not support authentication using PKI-based digital certificates.
Although the iLabs experience was a whirlwind of wireless integration completed in a very short period of time, it provides a snapshot of the current state of the 802.1x marketplace in terms of what products are available and how well they work together.
Starting With the Supplicant
The choices for 802.1x supplicant software are pretty limited. If you’ve made the jump to Windows XP or the .Net version of Windows CE, you’re in luck: it’s built-in. However, for other platforms, it’s not so easy.
Meetinghouse and Funk have Windows-based 802.1x supplicants for pre-XP Windows operating systems. Meetinghouse also offers a free client for Linux. The Open1x team, an open source group largely based at the University of Maryland, also has created an open source 802.1x supplicant for Linux, with Berkeley Software Distribution support promised in the future.
As an interim measure to full 802.1x support in its product line, Cisco has created a nonstandard version of 802.1x authentication called Lightweight EAP (LEAP). LEAP is built into Cisco’s wireless drivers that run on its Aironet adapters and is built in to its access points). These are available on most Windows platforms, Macintosh and Linux.
Network professionals who elect to go with LEAP as an interim step toward 802.1x shouldn’t see compatibility problems. In our testing, we combined LEAP and standard 802.1x using the same RADIUS server without problems.
Another issue to consider when selecting your supplicant is how it will interact with the authentication method for your wireless deployment. Although EAP has more than a dozen authentication methods defined, only four are commonly used. In addition to Cisco’s LEAP, there are: Message Digest 5 (MD5), a one-way authentication of supplicant to network using passwords; Transport Layer Security, which uses PKI-issued digital certificates for strong mutual authentication; and Tunneled TLS (TTLS), which combines network-based certificates with other authentication such as tokens or passwords.
In the iLabs, we tested all four methods. We found that while Cisco’s LEAP doesn’t offer the strongest security, it does service the most platforms – as long as you want to buy Cisco Aironet cards for your laptops and desktops.
MD5 authentication is the simplest to set up and configure, but also suffers from the weakest security. MD5 authentication only applies to the supplicant; the network is not authenticated. This opens your network up to man-in-the-middle attacks. In this regard, MD5 is so suspect that not every supplicant and authentication server supports it. While hacking 802.1x with MD5 isn’t easy (because it requires physical presence), it’s just a question of being closer to the client than the real access point.
Unfortunately, selecting anything stronger than MD5 means you need some sort of PKI in place to issue certificates. In the iLabs, we jumped this hurdle by using the built-in Windows 2000 Server certification authority.
TLS authentication uses digital certificates on both the authentication server and the supplicant sides. TLS is essentially the same protocol used in Web servers for “https:” URLs, also commonly used in secure Simple Mail Transfer Protocol, Post Office Protocol and Internet Message Access Protocol services. If you’ve already bought into a PKI solution, TLS authentication in 802.1x is a great option. TLS is standards-based and uses mature protocols. In our TLS demonstrations, we tested clients with certificates on different supplicants and even in a new HP wireless printer that supports 802.1x. Everything worked without problems.
If you don’t want to issue certificates to all your wireless users, you have to move onto TTLS authentication.
With TTLS authentication it’s easy to give certificates to your authentication servers, because you have so few of them. So you use those certificates for one-way TLS authentication (network to user), and once you have a nice, safe, encrypted and integrity-checked channel, you can use EAP inside of the TLS tunnel for any other authentication, such as a token or even username/password pairs. TTLS offers strong mutual authentication without having to distribute and manage certificates for all your users. The problem with TTLS is that it’s just a proposal within the Internet Engineering Task Force, not certain to be accepted, and support for it is only available in the Funk and Meetinghouse products.
The good news from iLabs is that we didn’t have any problems with interoperability in any of these cases.
We expected that the choice of which network adapter we used in our wireless devices would be irrelevant, and we were almost right. With Win 2000, our 802.1x supplicants required fairly recent versions of Network Driver Interface Specification driver upgrades for the wireless cards because some of the 802.11 object definitions that 802.1x relies on were not added to the Windows Developer Kit until after the NDIS Version 5.0 specification was out the door. Five of the six wireless cards we tried included the update.
Authenticators
“Authenticator” is a big word for what is essentially a simple function: unpacking EAP from 802.1x and packing it into RADIUS to pass to the authentication server. In that sense, we expected that any authenticator that supported 802.1x would work flawlessly all the time. But we were some authenticators actually look at the EAP packets and block certain kinds of authentication.
When selecting an authenticator – really, when selecting a wireless access point – make sure it supports not only 802.1x but also the authentication method (MD5, TLS, TTLS, etc.) you selected.
We also brought up two wired authenticators from HP and Cisco in the form of off-the-shelf enterprise switches that support 802.1x as a feature. We had no problems with our wired 802.1x switch testing and used some of the advanced features (such as virtual LAN switching based on user identification) to see the range and power of 802.1x beyond simple authentication.
The only interoperability issue we saw for wired or wireless authenticators was in WEP key establishment. When a wireless supplicant authenticates using a strong authentication method such as TLS or TTLS, the wireless access point is able to create a unique session key for use with WEP with that client. This dramatically increases the total security of WEP and makes it acceptable as an encryption protocol in a much wider range of network environments. However, not every authentication method supports establishing WEP keys. We also found some inconsistencies in configuring different access point/network adapter/supplicant combinations when it came to WEP and WEP key establishment. Keeping the authenticator and supplicant synchronized is very important for total system security. You don’t want to just authenticate and then not bother to turn on WEP.
Authentication Servers
We tested four 802.1x-compatible RADIUS servers from Funk, Microsoft, HP and Interlink. Additionally, we tested Secure Computing’s Premier Access server, which isn’t an EAP server by itself because it needs to piggyback on another product such as those Funk or Interlink offers.
We found that RADIUS servers varied along three major areas: operating system support, EAP authentication method support and back-end user database support. No server supported every possible combination out of the box.
At the iLabs, we had some high-powered on-site support, both from Funk and from HP, which let us do things with their servers that you wouldn’t do just from reading the manuals. However, we were testing every possible combination of authentication method, which means we stressed the servers more than a normal deployment would. In general, an enterprise wireless network would have one or perhaps two EAP authentication methods they would want to use, which dramatically decreases the aggravation in designing an 802.1x deployment.
When picking an authentication server, make sure to check with the vendor for current information. The server side of the equation is moving faster than any other part of 802.1x.
Wireless security testing will be an ongoing effort for the iLabs team with a second round slated to take place in August during the hotstage event for Networld+Interop 2002 Atlanta.
Joel Snyder is a senior partner at Opus One Inc., in Tucson, Ariz. He can be reached atjoel.snyder@opus1.com.
