Taking the Leap to PEAP for Wireless

Access points are proliferating, but there still are no formal policies or standards in place. Someone has to keep an eye on things. By Mathias Thurman

It's strange. Our company has yet to embrace wireless as a global deployment, yet every couple of months, the number of access points seems to double.

The other day, I received a call from one of the lab managers. He wanted to deploy a bar code system for asset tracking. The bar code reader would transmit information via Bluetooth to a Hewlett-Packard iPaq, which has a built-in wireless card. He wanted to deploy several access points so that the iPaq could communicate asset tag data in real time to a back-end database residing on our corporate network.

Another call came from one of our briefing centers, where the manager wanted some access points so that visitors could check their e-mail, make airline reservations, print itineraries or do general Internet browsing. I also found out that upper management has approved the installation of access points for every new facility that comes online. That's a lot of access points, since we're expanding in India, Singapore and China, and we've added offices in Virginia and other locations.

But despite this growth in wireless use, we still have no formal policies for wireless deployment or a project manager to oversee the spread of access points. Instead, network engineering and I are driving the entire process. Last week, we decided to abandon our Cisco LEAP implementation because of perceived vulnerabilities in the way that protocol handles passwords. Unless a strong password is used, hackers can easily compromise the wireless connection and gain access to our network. And having concluded that no matter what we chose there would probably be an exploit or published vulnerability at some point, we decided to deploy two-factor authentication to force people to use an RSA SecurID token before they can associate to an access point. Our hope is that even if a particular protocol becomes compromised, the two-factor authentication process will continue to protect us.

We explored several options and found that the only way to make use of our existing deployment of RSA SecurID tokens while getting two-factor authentication was to deploy PEAP. PEAP, which stands for Protected Extensible Authentication Protocol, was developed jointly by Microsoft, RSA Security and Cisco for transmitting authentication data, including passwords, over wireless nets. What sets PEAP apart from LEAP is that communications between the wireless client and the authentication server (Cisco ACS) are tunneled. With LEAP, the authentication information is passed in clear text. With PEAP, the authentication data is transmitted after the encrypted tunnel is created.

Working Things Out

We had a little trouble at first. Our users have Dell laptops that come with built-in wireless cards and client software called Dell TruMobile that's used to control the cards. The client has to generate a digital certificate to facilitate the tunneling, and it has to be compatible with Cisco Compatible Extensions Version 2 so it can interoperate with Cisco's version of PEAP.

The Dell TruMobile client is supposed to be compatible with CCE-2, but the implementation wasn't very straightforward, and documentation was lacking. After a lot of effort, we were able to get the Dell laptops to work with the Cisco access points and prompt us for a SecurID token code.

There are still some issues to work out, but I think that at the end of the day, we'll have a working RSA SecurID-protected wireless infrastructure.

One thing that the vendors are still trying to help us resolve is a 60-to-90-second lag before the SecurID dialogue box comes up; that's just too long for employees to wait.

One cool aspect of our deployment is that we'll be using virtual LAN tagging to segregate various levels of access to our wireless infrastructure. This means we don't have to buy and install separate access points for SecurID-protected employees, who need access to our internal network, and for guests, who will be allowed access only to external Internet resources. With VLANs (also called 802.1Q networks), we can configure two separate networks, each with its own wireless Service Set Identifier (a sequence of characters that uniquely identifies a wireless LAN) for associating to the access point.

For example, an employee using an SSID of, say, "emp" will be prompted to provide a SecurID token before being allowed to associate to the access point and gain access to internal corporate resources such as Exchange mail, shared folders, the company intranet and human resources sites. Meanwhile, a guest using an SSID of "guest" won't be prompted for a SecurID token in order to get to the Internet. The employee and the guest are connected to the same access point, but the different SSIDs they use to do so give them different access rights.

Best of all, Cisco will let us use VLAN tagging to create as many as 16 separate VLANs. That gives us a lot of flexibility in the way we provision wireless networks for the enterprise.

To help out that lab manager who wants to do asset tracking, we'll probably create a third VLAN that will be accessible from the asset-tracking HP iPaqs, perhaps with an SSID of "track."

To manage all these access points, SSIDs and VLANs, we'll continue to use the Cisco Wireless LAN Solutions Engine, since we can also use it in our continuing efforts to detect rogue access points. I'll talk more about that in a future installment.

What Do You Think?

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com, or join the discussion in our forum at QuickLink a1590.

To find a complete archive of our Security Manager's Journals, go to


Copyright © 2004 IDG Communications, Inc.

Shop Tech Products at Amazon