Biz & IT —

Wireless Security Blackpaper

The ins and outs of wireless network security.

For a long time, most people considered VPN as the definitive solution for handling wireless security. The idea behind this security measure is to consider the wireless network equivalent to the Internet. Companies use a firewall device at the point where their network connects to the Internet, and only allow users in via an encrypted, secure channel. The same idea applies to their wireless networks. Using the VPN solution, all wireless network traffic is segmented behind a firewall. Each client is then configured with a VPN client and tunneled over the wireless network to a VPN concentrator on the wired network. This security setup uses a secure, proven technology to prevent outsiders from gaining access to your wired network. Also it reuses a technology many companies have already deployed, so there is very little added expense in those cases.

There are a few weaknesses with this setup however. The process of gaining legitimate access to a wireless network begins with the client booting up and getting an IP. Once the client has an IP, through either static addresses or more commonly DHCP, the client can then negotiate a tunnel over the wireless network to begin its communications. Illegitimate users go through the exact same process, except that they do not gain direct access to the wired network. Because the attacker has been given an IP, though, there is nothing preventing him from communicating with other wireless clients on their side of the firewall. By communicating with other wireless clients the attacker has the possibility of breaking into an authorized user and gaining access through their client. It is possible to prevent this by allowing the wireless user to only communicate with the VPN concentrator point, but that feature is available in only some of the VPN clients out there. The added burden of having to lock down each client as well as the wireless-to-wired network connection makes this a more difficult situation to implement than it might seem on the surface.

Even if you do manage to lock down the clients on your network and prevent them from accessing the wired network at all, you are still handing out IP's to anyone who asks. This means that it is possible for unauthorized wireless users to piggyback your wireless connection to communicate to other non-VPN clients on the same network segment. This means that Joe Cracker and Suzy Cracker can communicate with each other across your campus, but not your other internal networks. Because network bandwidth is shared on a wireless connection and there is only currently 11Mbits to go around, this type of piggybacking can cause extreme performance hits on your wireless network, and deny legitimate users the bandwidth they need for their applications.

VPN solutions can be an effective way of preventing unauthorized users from gaining entry to your wired network as long as they are implemented correctly. There are other concerns though which might make a wireless administrator think twice about implementing it.

802.1X is a standard which was ratified in early April by the IEEE regarding port level security. Initially it was intended to standardize security on wired network ports, but it was found to be very much applicable to wireless networking as well. This new layer 2 (MAC address layer) security protocol exists at the authentication stage of the security process. Using 802.1X, when a device requests access to the AP, the AP demands a set of credentials. The user then supplies some form of credentials which the AP then forwards to a standard RADIUS server for authentication and authorization. RADIUS stands for Remote Authentication Dial-In User Service, and is commonly used to authenticate dial-in users. The exact method of supplying credentials is defined in the 802.1X standard EAP (Extensible Authentication Protocol). EAP is an authentication "bucket" that allows developers to create their own methods of passing credentials and is the main security measure in 802.1X. There are four commonly used EAP methods in use today. They are EAP-MD5, EAP-Cisco Wireless (also known as LEAP), EAP-TLS, and EAP-TTLS.

EAP-MD5 relies on an MD5 hash of a username and password to pass credentials to the RADIUS server. EAP-MD5 offers no key management or dynamic key generation, requiring the use of static WEP keys. This prevents unauthorized users from accessing your wireless network directly, but offers nothing over the proven insecure static WEP encryption scheme. Attackers can still sniff your airborne traffic and decrypt the WEP key. Once the key is decrypted they can easily watch all data running over your wireless network. Another flaw in EAP-MD5 is that it offers no way for the wireless client to verify the AP. Because of this, a determined attacker could plant a rogue AP on your network and fool your wireless clients into thinking that it is a secure communications point. Because it offers no other features over the
standard 802.1X, EAP-MD5 is considered the least secure of all the common EAP standards.
?

EAP-Cisco Wireless, or LEAP, is a standard developed by Cisco in conjunction with the 802.1X standard, and is the basis for much of the ratified version of EAP. Like EAP-MD5, LEAP accepts a username and password from the wireless device and transmits them to the RADIUS server for authentication. What sets LEAP apart from EAP-MD5 are the extra features it adds over what is explicitly called for within the 802.1X/EAP specification. When LEAP authenticates the user, one time WEP keys are dynamically generated for that session. This means that every user on your wireless network is using a different WEP key that no one knows, not even the user. Also, you can combine this with the session timeout feature of RADIUS to have the user re-login every few minutes (handled behind the scenes, the user doesn't have to
type anything in) and create new dynamic WEP keys that change every few minutes. Setting your RADIUS server up this way effectively nullifies current attacks on WEP because the individual keys are not used long enough for an attacker to crack them. LEAP also stipulates mutual authentication of client-to-AP and AP-to-client above what 802.1X strictly calls for. This prevents a hacker from inserting a rogue AP into your network and fooling your wireless clients into thinking it is a secure connection.

?
There are presently two drawbacks to running LEAP. First, the mechanism of passing the logon credentials uses MS-CHAPv1 for both the client and AP authentication. This version of MS-CHAP has known vulnerabilities, and can be compromised by a determined enough attacker with the right tools. There are no known instances of LEAP being compromised by this, but MS-CHAPv1 is a weakness. The second drawback in implementing LEAP is that LEAP currently only works on Cisco end-to-end networks, because only Cisco has added LEAP capabilities to their wireless client. Other vendors, however, are working to add LEAP to their wireless client software to allow non-Cisco network cards in established LEAP implementations.

EAP-TLS was developed by Microsoft, and is outlined in RFC 2716 . Instead of username/password combinations, EAP-TLS uses X.509 certificates to handle authentication. EAP-TLS relies on Transport Layer Security, the IETF's attempt at standardizing the Secure Sockets Layer (SSL) to pass PKI information in the EAP bucket. Like LEAP, EAP-TLS offers dynamic one-time WEP key generation, and authenticates the AP to the wireless client as well as the client to the AP. EAP-TLS runs on any platform that has a client written for it. Currently clients for EAP-TLS are implemented through several vendors for Linux and all flavors of Windows (except CE).

?
The first hindrance to implementing EAP-TLS is in the burden of PKI. If your organization does not already have a PKI in place handing out certificates to trusted parties there is a potentially steep learning curve in figuring out exactly what PKI is and how to implement it. Once you get the PKI services installed and implemented, handing out certificates is not too much of a burden. The main impedance to EAP-TLS right now is the general confusion surrounding exactly how to do it. The only way to currently easily deploy EAP-TLS is if you are in an Active Directory (AD) using a Microsoft Certificate Server with wireless clients that only log into the AD, and all your certificates are published to the user accounts in the AD. Problems crop up when you want to change any part of that.
?
If you are using some other directory service such as Open LDAP or NDS, then you can't publish the certificates to the user accounts, and the RADIUS server has no standards-based way to tell if the certificate you are passing it is a valid one for the account you send it. If you want to use some other certificate server you run into issues between the EAP-TLS standard as written and the interpretation of the X.509 standard for certificates. There is an optional field called "Extended Key Usage" that exists in all Microsoft certificates. This field is used to determine what the certificate is used for. Either mail signing, code signing, or user authentication. In a Microsoft Certificate Services certificate, that field always exists and, if you use the certificate for all purposes it contains every value. If you are using a
Verisign issued certificate for every purpose that optional field doesn't exist at all. Since EAP-TLS looks for a specific value in that field, if you have a general Verisign certificate you can't use it. If your wireless client doesn't log into the Active Directory, then the Certificate Services will not issue it a certificate at all.
?
See, confusion. Unless your organization can take The Microsoft Way? document straight from MS and implement it just how they have it, EAP-TLS should be considered a work in progress, and not quite ready for primetime. Currently there are vendors working to address these confusing issues, however, and in the next few months TLS should be ready for the spotlight.

EAP-TTLS was pioneered by Funk Software as an alternative to EAP-TLS. The AP still identifies itself to the client with a server certificate, but the users now send their credentials in username/password form. EAP-TTLS then passes the credentials in any number of administrator specified challenge-response mechanisms (PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PAP/Token Card, or EAP). The only challenges to EAP-TTLS are the slightly less secure than dual certificates of EAP-TLS, and the upcoming standard developed by Microsoft and Cisco that works exactly the same way called Protected EAP (PEAP).