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 Tunnelled 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 vendors 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.
PEAP vs TTLS: a bad competition
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.
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 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. 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.
Snyder is a senior partner with consulting firm Opus One and a member of the Network World Global Test Alliance
‘Park and pry’ hampered WLAN uptake
Wireless LANs became the industry’s laughing stock when reports surfaced about “car park attacks” on corporate networks. Now, WLANs are shaping up as the battleground for enhanced security products that could lead the way for the entire network industry.
WLANs are not inherently insecure. There is an explanation for why unauthorised individuals were able to wirelessly access corporate networks from car parks: The people who installed WLANs at those firms never bothered to activate their built-in security features. Duh.
That’s not to say WLANs don’t pose unique security risks. Wireless hackers are hard to detect and trace, so WLANs are tantalising targets. And employees unwittingly might compromise corporate security by attaching wireless access points to the corporate network without informing the IT department.
The car parks attacks did real damage to the WLAN industry, coming just as WLANs gained widespread acceptance in companies and among hot-spot operators. The WLAN industry is growing, but not as fast as it would have. More importantly, wireless networks increasingly are interconnected with wired networks; it no longer makes sense to think of wireless security as an isolated problem. So what should a first-class WLAN security product look like? It must address three fundamental concerns: privacy, access fraud and intrusion. Privacy can be assured by using an encryption mechanism that changes codes faster than hackers can crack them.
Hackers are continuously devising new strategies for penetrating networks and a framework protocol letting vendors stay at least one step ahead of the hackers is needed.
Developing satisfactory WLAN security is a challenge. Security is only as good as its weakest link, so enhanced products must be implemented end to end. That means they must be based on universally accepted standards. Unfortunately, the IEEE 802.11 WLAN standards committee has a history of acting slowly.
The WLAN industry simply cannot afford to wait. When the Wired Equivalent Privacy standard proved vulnerable, the Wi-Fi Alliance quickly created Wi-Fi Protected Access (WPA). Now Cisco is trying to move things further along — and in its direction — through its Cisco Compatible Extensions program.
All networks are susceptible to eavesdroppers and gatecrashers. The key difference between the WLAN industry and the larger Internet community is that wireless vendors understand they can no longer get by with half measures. Everyone concerned about Net security should follow closely, if not participate in, the development of enhanced WLAN security standards.