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.BELMONT, CALIF. - In interoperability testing that NetWorld+Interop's\u00a0iLabs Wireless Security\u00a0team conducted earlier this month, we found that products supporting 802.1X\u00a0-- the proposed standard for authentication in wireless networks\u00a0-- worked well together most of the time, but we identified some problem areas that need attention from standards bodies and vendors alike.The\u00a0iLabs\u00a0team assembled\u00a0802.1X\u00a0supplicants (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\u00a0security \u00a0measures into an existing authentication system, such as username\/ password or token-card schemes. Unfortunately, that's not easy to do securely.PEAP vs. TTLS: A bad competitionTwo competing proposals that help to integrate legacy authentication into 802.1X are TTLS, proposed by\u00a0Funk\u00a0and\u00a0Certicom; and PEAP, proposed by\u00a0RSA Security,\u00a0Cisco\u00a0and\u00a0Microsoft. 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\u00a0Lightweight Directory Access Protocol \u00a0directory, 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\u00a0-- 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\u00a0-- the two vendors driving PEAP, have chosen an incompatible set of inner authentication methods, blocking total interoperability. Smaller vendors, such as\u00a0Meetinghouse Data Communications\u00a0and\u00a0Interlink , 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\u00a0Alfa & Ariss \u00a0has 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.Setting WEP keysOne 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\u00a0IP 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.Is it standard or not?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\u00a0Dynamic Host Configuration Protocol\u00a0requests, 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.\u00a0Aruba Networks\u00a0and\u00a0Trapeze Networks\u00a0were 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.Renamed MPLS team looks to servicesILabs\u00a0has a deep-rooted history in testing how well\u00a0Multi-protocol Label Switching\u00a0can work for service providers and their corporate customers (click here for more). After several years of testing basic MPLS support in network gear, the\u00a0Advanced Internetworking Initiative iLabs\u00a0team is looking upward at the technologies and services that can be delivered across MPLS-based networks. The team is targeting how MPLS can carry VPN tunnels, enable quality-of-service technology, and meet the demands of delivering\u00a0IPv6\u00a0traffic.Back to main iLabs package: "iLabs engineers cook up 802.1X, iSCSI, MPLS tests"