BELMONT, CALIF. - In interoperability testing that NetWorld+Interop's iLabs Wireless Security team conducted earlier this month, we found that products supporting 802.1X -- the proposed standard for authentication in wireless networks -- worked well together most of the time, but we identified some problem areas that need attention from standards bodies and vendors alike.
The iLabs team assembled 802.1X supplicants (clients) from four vendors on four operating systems (Windows XP, Windows 2000, Mac OS X and Windows CE); Remote Authentication Dial-In User Service (RADIUS ) authentication servers from seven vendors running on Windows, Linux and HP/UX; and 19 different 802.1X wireless and wired devices including access points, new wireless switches and traditional wired Fast Ethernet switches.
Across the board, we identified hundreds of test cases that worked flawlessly. However, testing uncovered instances where interoperability wasn't so smooth, including complications with Protected Extensible Authentication Protocol (PEAP) and Tunneled Transport Layer Security (TTLS) authentication within 802.1X, setting of wired equivalent privacy (WEP ) keys, and interpretations of the standards.
Vendors achieved excellent Transport Layer Security (TLS ) authentication rates in our lab setting, with only a few test cases failing. TLS, and IETF-sponsored protocol, is the simplest acceptable authentication method for wireless networks, and has been accepted as a standard, therefore it served as a litmus test for basic operation.
But in the real world, things are much different. TLS requires that each end user have a digital certificate, and that's probably not a good assumption for many of today's networks. Conventional wisdom for wireless vendor lies in the belief that most network managers will want to incorporate 802.1X-based security measures into an existing authentication system, such as username/ password or token-card schemes. Unfortunately, that's not easy to do securely.
Two competing proposals that help to integrate legacy authentication into 802.1X are TTLS, proposed by Funk and Certicom; and PEAP, proposed by RSA Security, Cisco and Microsoft. While neither proposal has advanced to standards status, many vendors have implemented both.
Finding a compatible inner authentication method, such as MS-CHAP-V2 or One Time Password, within PEAP and TTLS is not easy. Because PEAP doesn't allow for a simple username/password mechanism required to authenticate against an existing user database with encrypted passwords, such as Unix or a Lightweight Directory Access Protocol directory, vendors have tried to shoehorn this into PEAP authentication methods. The results are predictable: Every vendor has a different approach, and that translates to interoperability failures.
TTLS has the opposite problem: There are too many ways to do the same thing. So if you want to authenticate against a Microsoft authentication database with MS-CHAP-V2, there are two ways to do it -- and not every vendor allows for both possibilities.
Because TTLS and PEAP are technically equivalent, having both on the table at this stage of the 802.1X implementation is a major roadblock to interoperability. During the testing, we found different vendors have implemented different drafts. Even Cisco and Microsoft -- the two vendors driving PEAP, have chosen an incompatible set of inner authentication methods, blocking total interoperability. Smaller vendors, such as Meetinghouse Data Communications and Interlink , also are being pushed to implement both standards, further diluting development efforts and complicating implementation and interoperability. While time will improve interoperability, having the IETF decide the TTLS vs. PEAP discussion quickly would help even more.
Users who want to use simple username/ password have another option. Dutch network security firm Alfa & Ariss has made available a freeware TTLS plug-in, which adds TTLS with Password Authentication Protocol (the simple username/password method) support to Microsoft's built-in Win 2000 and XP 802.1X supplicant. (For a download, go to www.alfa-ariss.com.) We tested this freeware and got it to interoperate with the other products tested.
If you want to use TTLS or PEAP to authenticate wireless users, hold off committing to a final wireless security topology for several months until the IETF chooses a final direction.
One plus for 802.1X authentication is that wireless access points maintain a fairly neutral position, mostly packing and unpacking EAP (the inner protocol being carried by 802.1X) packets as the supplicant talks indirectly to a RADIUS server. Inside of EAP are the actual authentication methods, such as TLS, TTLS and PEAP. However, at the end of the process, the RADIUS server has to communicate with the access point to give it enough information to set the WEP keys. Without this final step, 802.1X authentication doesn't provide an encrypted channel.
Our testing discovered a number of cases where the 802.1X authentication succeeded, but communications between the RADIUS server, the access point and the supplicant fell apart. This is a particularly difficult problem to debug, not only because it has to do with moving encrypted data around, but also because all three parties have the opportunity to make errors.
A few vendors also ran into problems during reauthentication tests called for by the iLabs test plan, because these went beyond the normal cursory checks included in most interoperability tests. As with IP Security, reauthentication is a problem that's hard to test for, but can cause major user dissatisfaction and interoperability failures down the road.
Virtually all the vendors failed one test: setting a short, 40-bit WEP key. While most products support the widely accepted 104-bit WEP keys, 802.1X compliance calls for 40-bit keys. If you jumped on the wireless bandwagon early and bought cards that only support the shorter key length, you might want to consider replacing any 40-bit-only equipment during your 802.1X rollouts.
Because 802.1X, EAP, TTLS and PEAP are relatively young standards -- TTLS and PEAP are still drafts -- there is not complete agreement on how to interpret and implement them. We coached a number of vendors through practices such as rekeying sessions, timing of Dynamic Host Configuration Protocol requests, virtual LAN (VLAN) switching and certificate management.
Although these implementation choices, such as how to select a VLAN for an 802.1X user, wouldn't necessarily cause failures, they could mean that network managers are getting something different from what they bargained for, at least until the participating vendors begin to converge on one approach and agree formally and informally.
This problem wasn't specific to any one kind of vendor. Some of the newest wireless switch vendors that haven't even announced products had standards interpretation issues. However, their commitment to send engineers to the test event paid off. Aruba Networks and Trapeze Networks were able to quickly update their software overnight to help increase total interoperability with other vendors. The biggest players, including Microsoft, also found that their implementation of the standards and drafts didn't match everyone else's.
Most vendors told us that they will follow two paths: whatever the standard says, or if that's not enough, whatever it will take to interoperate with the big guys. Because Microsoft is providing an 802.1X client in Win 2000 and XP, most consider Microsoft's PEAP implementation a reference they must match. This is good news for customers who are counting on built-in support in Windows and want to use the PEAP path for authentication.
Although the iLabs testing showed that 802.1X interoperability isn't a foregone conclusion, the number of vendors and their enthusiasm towards interoperability says that 802.1X certainly can be factored into your wireless plans.
Joel Snyder is a senior partner with Opus One, a consulting firm in Tucson, Ariz.