Beyond WEP

By Steven J. Vaughan-Nichols

October 29, 2002

Everyone agrees that there's got to be something better than Wired Equivalent Privacy (WEP) for wireless security. The real question is: what will it be?

Everyone agrees that there's got to be something better than Wired Equivalent Privacy (WEP) for wireless security. The real question is: what will it be?

Some companies have decided to take WEP into their own hands and improve it. These include Agere Systems with its 152-bit WEP and US Robotics and D-Link with 256-bit WEP. While increasing the encoding bits does make breaking a WEP communications more difficult, it doesn't fundamentally improve wireless network security.

You see, WEP's practical problem has always been that administrators tend to stay with the same key for months, because there's no easy way to transfer new WEP keys. They have to manually set them in each access point and NIC. With a small key, WEP's typical 40 bit-key, a cracker can pick up enough frames based on the same key to figure it out in hours. A longer key, even 256-bits, just means that a cracker needs to collect more data. Thus, while a long key will certainly discourage casual data raiders, if someone is determined to be a wireless spy, they do it with a few weeks of data collecting.

And, of course, if you buy into any of these proprietary WEP encryption schemes, you're stuck with buying all your wireless equipment from a single vendor.


So why not just use a stronger encryption? That's exactly what Advanced Encryption Standard (AES) supporters say. And, AES's new Rijndael algorithm with its 128, 192 and 256 bits key-lengths is suppoused to be much stronger than the WEP.

That's the good news. The bad news is that AEP requires much more processing firepower than WEP did. In fact, it's expected that AES will require a separate processor to avoid slowing down Wi-Fi communications. That, of course, means that it won't be backwards compatible. Although AEP has been receiving wireless vendor support since December 2001, no one has yet shipped, or appears to be even close, to shipping AES-enabled equipment.


In theory, IEEE's 802.1X provides a vendor-independent way to control access to wireless networks by port control. In practice, it's not that simple.

While parts of 802.1X are indeed standard, it uses port control with dynamically varying encryption keys that can be automatically updated over the network with the Extensible Authentication Protocol (EAP) to enable user, not machine, authentication. To make all this happen, 802.1X uses RADIUS servers.

However, 802.1X doesn't require the use of Remote Authentication Dial-In User Service (RADIUS) authentication. Instead a variety of authentication methods, such as certificates, Kerberos and public key authentication can be supported. Which, in turn, means that your laptop, even if has 802.1X enabled and is trying to connect with a open WLAN won't be able to connect... unless your client PC is running the same authentication method used by the 802.1X authenticator software behind the access point. For example, if you're using Cisco's Lightweight EAP (LEAP) on your laptop and the local access point uses Microsoft Point-to-Point Encryption (MPPE), there no hope of making a connection.

Thus, while 802.1X is fine for a closed wireless network, it's lack of a standard implementation method makes it less than ideal for, say, Jane Traveler jumping from office WLAN to hotel WLAN to conference center WLAN and so on.

Another practical problem with 802.1X is that it's still being deployed. While 802.1X is supported in Windows XP, Windows 2000 and 98 don't have native support. There are ways around this, but 802.1X is hardily plug and play for users with older systems. It also isn't widely supported yet on access points, especially low-end products. Combine this with the need for a RADIUS server and you have a security solution that's will work for many businesses, but is probably beyond the reach of most SOHO users.

Still another problem: 802.1X only handles authentication. The data inside an 802.1X is only as secure as its encryption makes it. If you use WEP you're still stuck with all of its problems. Some people think that because 802.1X can dynamically update its authentication keys so you can forego the updating administration misery. It doesn't. You still have to manually update WEP keys on every device if you have any hope of WEP actually protecting you.

It might take longer for a cracker to break an 802.1X connection, but a patient cracker after your office secrets could still get enough traffic to spoof his way into your network.

You don't have to be that patient. There are two documented ways to break into 802.11x: session hijacking and man-in-the-middle. In session hijacking, a cracker makes it look to someone who just connected with the access point that they've been booted off. In the meantime, the cracker connects in with the still active 802.11-based connection leaving both the network administrator and the user in the dark.

In 'man in the middle,' a cracker pretends to be an 802.11x access point to the user and, using the picked off credentials of the user, becomes a user to the real access point. This works because in 802.11x only the client is authenticated. There's no way for the client to be certain that it's hooked straight into a legal access point.

Indeed, when you consider just how many incompatible ways that 802.1X can be deployed, and still meet the standard, it appears as if 802.1X will be more trouble than its worth to many wireless users and enterprises.


Virtual Private Networks (VPN)s are also being suggested as ways to handle wireless security. These come in a many forms using both tunneling protocols such as Generic Routing Encapsulation (GRE) and Layer Two Tunneling Protocol (L2TP) and encryption protocols like MPEE and IP Security Protocol (IPSec) .

After years of use on the Internet, there are a bewildering variety of incompatible VPN programs. Even using open standards, such as the combination of L2TP and IPSec, an Internet Engineering Task Force (IETF) proposed standard, doesn't guarantee that one company's L2TP/IPSec package will work with another's. Any given package, properly deployed, will work better than ordinary WEP, but they're not universal solutions.


Yet another approach is to use stronger encryption that WEP supplies. While there are several attempts to do this, 802.11i is the official IEEE attempt to supply strong security for wireless links. Unfortunately, 802.11i is still a work in progress.

When completed, 802.11i will use Temporal Key Integrity Protocol (TKIP). TKIP addresses the WEP static key problem by dynamically updating the key, based on WEP's own RC4 encryption across all devices once for every 10,000 packets transmitted. For vendors, the good news is that existing devices can be updated with firmware updates. The bad news is that 128-bit RC4 changed every 10,000 packets is still breakable. Even TKIP supporters admit that, at best, it's a stopgap solution to wireless security.

To expand 802.11i's lifespan, its IEEE committee also plans to replace RC4 with AES. 802.11i is being designed to work hand in glove with 802.1X. Still, when 802.11i does arrive it appears almost a lead pipe cinch that you'll need to replace all your Wi-Fi equipment to make use of it.

Security Today

Frankly, there is no universal approach that will give you 99.9999% security. You can come close to it by practicing good network security and using a proprietary VPN solution, but that's as good as you're going to get.

If you have people on the road, forget about it. There is no way you can currently guarantee their network security.

That isn't to say that it's hopeless. Simply using basic WEP and elementary security practices such as avoiding the use of Dynamic Host Configuration Protocol (DHCP) on your access points will go a long way to keeping most casual snoopers out.

If security is vital to you, then you're going to have go to the time, trouble and expense of deploying a proprietary approach. For today, and tomorrow, there's no other way to do it.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.