Two roads diverged toward WLAN security

For some time now, there's been no question in my mind that the best route to establishing a secure wireless LAN goes through an AAA server. Also known as a remote authentication dial in user service (RADIUS) (based on its support of an Internet Engineering Task Force standard, a AAA server handles authentication, authorization, and accounting functions for users looking to gain access to a network.

As the "dial in" part of RADIUS suggests, RADIUS/AAA servers were not designed to lock down wireless networks. But when coupled with security based on the IEEE 802.1x standard ] for port access control, RADIUS servers are perfect for securing wireless networks as well. That's because of the way wireless access points act like port providers to client systems attempting to connect to a LAN via one of the WLAN standards or drafts (802.11b, 802.11a, or 802.11g).

But despite the apparent robustness of the WLAN security stacks, there is a dispute over how WLAN clients and RADIUS servers should go about securely exchanging credentials. This exchange normally takes place over a protocol called EAP (Encapsulated Authentication Protocol). Any wireless traffic bearing that credential information is up for grabs to those with malicious intent. Securing those credentials in a wireless scenario requires yet another protocol -- one for which no standard has yet to be set. And wherever there's a need for a standard, plenty of vendors are willing to jump in with proprietary offerings in hopes of locking in customers.

At the top of the list are three such schemes: LEAP, PEAP, and TTLS. LEAP, or lightweight EAP, has been one of the keys to Cisco's success in the wireless arena. Long before the PEAP and TTLS alternatives started to get any traction, Cisco was solving the secure exchange of credential information by embedding LEAP support in its WLAN adapters and RADIUS/AAA server (CiscoSecure Access Control Server). With few other vendors supporting LEAP on the RADIUS/AAA-side or the client-side, early WLAN adapters going down the LEAP path ended up buying all of their gear from Cisco.

In partnership with Microsoft, however, Cisco is now endorsing PEAP (protected EAP) as a somewhat more interoperable LEAP replacement. Meanwhile, other RADIUS/AAA solution providers like Funk Software and Certicom are promoting an alternative called TTLS (Tunneled Transport Layer Security). Both PEAP and TTLS are under consideration by IETF, but there's no word so far on which will emerge as a standard, or whether the differences will be reconciled into one standard.

The two schemes are architecturally similar. Each sets up a secure tunnel between the client and RADIUS/AAA service through which credential information can be passed, unavailable to prying eyes. The server sends the client a certificate so that the client knows it's talking to the right server. Once that's established, the two set up a tunnel through which credentials can be passed.

But where they differ, and where Funk Software vice president Joe Ryan is trying to educate buyers, is in the flexibility on both the client and server sides.

"The way to do it," said Ryan, "is to provide a solution that allows companies to secure wireless clients of all types as well as to keep their existing security infrastructure in place. It doesn't matter what you have in place. It could be single factor or two-factor security scheme on any mix of clients going up against an NT Domain, an Active Directory, an LDAP-based directory, or a SQL database." According to Ryan, this flexibility is the hallmark of Funk's Odyssey and Steel Belted RADIUS solutions.

"With PEAP," said Ryan, "full client support is available for Windows XP only, and it will only authenticate against an NT Domain or an Active Directory [both of which are Microsoft technologies]." This is true if your AAA service is Microsoft's, but Cisco's CiscoSecure ACS also supports multiple backend authentication databases.

Indeed, TTLS clients are available for virtually every client (Linux, Mac OS X, Windows 95/98/ME/N/2000/XP). A document published late last year on the O'Reilly Network does a nice job of comparing the availability of support for both TTLS and PEAP. Even so, just as Cisco wants you to buy its gear, and Microsoft wants you on Active Directory and gives away RADIUS functionality to help get you there, Funk has its own proprietary blend of TTLS that, Ryan said, offers one other advantage over the PEAP implementations: scalability. Built into Funk's Odyssey clients (which only support the primary flavors of Windows as well as PocketPC) is the ability to push new software and configuration information out to client systems. The PocketPC client, which was just introduced, lacks the push capability.

According to Ryan, "We have an enhanced version of the client which adds a preconfiguration capability for network administrators who want to deploy clients to many users instead of going into each client system. The administration can create a configuration profile once and push that out to all users. Users don't have to do any configuration of the client, other than making sure the client is installed. The client also supports autoscanning for networks so that each user has a list of preferred networks so that as those users move between different parts of a campus or building, or between "nets" (ie: accounting to marketing) or even from the office to the home, our autoscanning will pick up preferred network."

Another advantage of Funk's solutions is their ability to work with vendor-specific features for existing network infrastructure such as networking switches and VPN (virtual private network) servers. As it turns out, vendors of both support most standards that are germane to either, but also extend that functionality with proprietary offerings. In the case of VPNs (all of which support some base level RAIDUS/AAA functionality), Funk's RADIUS/AAA solutions can be tied directly to proprietary mechanisms like time of day access restrictions found in VPN solutions from Nortel, 3Com, Checkpoint and others.

Could Cisco and Microsoft go as deep on TTLS as they have on PEAP? T there's no reason they can't, he said. "All of the code to implement TTLS has been completely open sourced. But ultimately, what sells our solution is that flexibility to leave everything you have --- from clients to directories to VPNs --- in place and to centrally administer everything."

Meanwhile, we can only wait to see whether PEAP, TTLS, or some combination of the two will prevail.

Is your wireless security brew complete, or are you still cobbling together a solution that aims to keep prying eyes from your sensitive traffic. Share your configurations or just comiserate with your fellow ZDNet readers in our TalkBack forum, or e-mail me at david.berlind@cnet.com.