Securing Wireless

Bill wraps up his three-part series on building a wireless infrastructure by discussing security protocols.

• By Bill Boswell
• June 01, 2003

Using 802.1x requires support in the wireless firmware, as well as suitably configured drivers. If you’ve already invested in equipment that doesn’t support 802.1x, you don’t need to scrap your hardware. You can use a virtual private network (VPN) to protect your wireless communications. Figure 1 shows a typical configuration. Note that the access point lies physically outside the firewall and connects to the VPN concentrator rather than to the DMZ network.

Figure 1. In a wireless VPN, the station makes its initial association to the access point using open authentication, not WEP. The user then launches a VPN client to establish an encrypted tunnel to a VPN concentrator.

The wireless stations associate to the access point using open authentication, avoiding any need for configuring Wireless Encryption Privacy (WEP) keys. Once the underlying network connection is in place, the user employs client VPN software to establish a protected tunnel into the DMZ and, from there, to the network. VPN concentrators typically use Remote Access Dial-in User Services (RADIUS) to authenticate users. Windows 2000 Internet Authentication Service (IAS) provides RADIUS services, but you can also install third-party products such as Steel-Belted RADIUS. All data between the client and the network is encrypted inside the VPN tunnel, so it doesn’t matter if someone eavesdrops using AirSnort or AiroPeek or Wireless Sniffer. You should still take the precaution of changing the Extended Service Set Identifier (ESSID) of the access point and disabling ESSID broadcasting. This discourages war drivers (data vandals who cruise around looking for open access points). ESSID was discussed in the first part of this series in the April issue.

Using a VPN to protect wireless connections has two primary disadvantages. First, the VPN clients exact a performance penalty that gets worse as you deploy high-speed, 54Mbps 802.11a and 802.11g equipment. The other disadvantage is flexibility. High-performance VPN concentrators carry a hefty price tag. If you have a large campus, it can become complex to configure the Ethernet connections from several access points to lead to the same VPN concentrator. If you install multiple VPN concentrators, you must deal with mobile stations that can’t reassociate with new access points as they move.

802.1x Wireless Security
As you may recall from last month’s column, standard WEP uses a 40-bit or 104-bit shared encryption key and a 24-bit dynamic Initialization Vector (IV) to construct a 64-bit or 128-bit encryption key. The shared portion of the key is static, and the dynamic IV is exchanged essentially in the clear. Both the static shared key and the small 24-bit IV represent security vulnerabilities.

802.1x addresses these vulnerabilities by defining a new Extensible Authentication Protocol (EAP) mechanism called EAP-over-LAN (EAPOL), which permits a station to authenticate to a network access point using RADIUS, then securely exchanging dynamic encryption keys. The cipher material used to protect this key exchange is generated by the TLS PseudoRandom Function (PRF) described in last month’s article. Here’s how the key exchange works (see Figure 2):

1. When presented with an association request from a wireless station (in 802.1x parlance, a supplicant), an access point repackages the request as a RADIUS Access Request message and passes it to a RADIUS server.

2. The RADIUS server authenticates the wireless station then uses the TLS PRF to generate a set of Microsoft Point-to-Point Encryption (MPPE) keys. (The PRF hints used to generate these keys are documented in the 802.1x standard. The MPPE format is documented in RFC 2716.) The RADIUS server generates one MPPE key (the RECV key) for encryption and one (the SEND key) for signing. It then sends the MPPE keys to the access point inside a RADIUS Accept message.

3. The access point generates two random WEP keys and encrypts and signs them using the MPPE keys it obtained from the RADIUS server. The access point then sends each encrypted WEP key to the wireless station inside individual EAPOL-Key messages. Figure 3 shows a packet capture of this transaction.

4. The station uses the same PRF inputs as those used by the RADIUS server to generate an identical set of MPPE keys that it uses to decrypt the WEP keys.

5. The station then uses one of the WEP keys to encrypt the data stream and keeps the other in standby to use during key-refresh transactions.

Figure 2. In a basic 802.1x EAPOL transaction, an access point generates a dynamic encryption key, then encrypts the key using cipher material obtained from a RADIUS server. The client generates the same cipher material and uses it to decrypt the dynamic key.

Figure 3. Packet capture of a RADIUS Accept message that contains the MPPE keys generated by the RADIUS server and sent to the 802.1x access point. (Click image to view larger version.)

802.1x Security Protocols
The 802.1x standard doesn’t define a specific protocol to use for authentication or key generation. Several protocols have emerged in the wireless arena, all of which use SSL/TLS in some fashion. Here is a brief survey of the most commonly used protocols:

EAP-TLS—RFC 2716 documents a mechanism for encapsulating Transport Layer Security (TLS) authentication messages into standard EAP messages. EAP-TLS uses the authentication portion of TLS to generate and exchange dynamic WEP keys. TLS uses public-key certificates to identify computing entities, so EAP-TLS requires that the RADIUS server and each wireless station have a certificate. This involves deploying a Public Key Infrastructure (PKI). EAP-TLS was proposed by Microsoft and has been widely adopted by wireless vendors.

Protected EAP (PEAP)—This mechanism was proposed by Microsoft, Cisco and RSA. Its major advantage over EAP-TLS is that it validates the user’s identity rather than the station’s identity. This eliminates the need for computer certificates at each station. It also resolves a security deficiency in EAP-TLS in which a stolen laptop can still be used to gain wireless access until the certificate is revoked. As of this writing, only Cisco provides access points and wireless adapters that support PEAP.

Lightweight EAP (LEAP)—LEAP is a proprietary Cisco protocol similar to the PEAP mechanism promulgated by Cisco and Microsoft. The authentication protocol in LEAP relies on Cisco authentication services.

EAP-TTLS (Tunneling TLS)—PEAP (and, to some extent, LEAP) share a disadvantage: They both have Microsoft’s name in the header of the RFC documents. Tunneling TLS differs from PEAP and LEAP in that it provides for negotiation of the authentication protocol used within the TLS tunnel, thus avoiding reliance on a single vendor’s authentication mechanism.

EAP-TLS
EAP-TLS uses the TLS Handshake Protocol to authenticate a wireless station. This is an industry-standard mechanism with a proven track record. A TLS Handshake transaction has an additional advantage of permitting a client to validate the identity of the authenticating server to avoid man-in-the-middle exploits. Figure 4 shows the actors in an EAP-TLS transaction.

Figure 4. In an EAP-TLS transaction, both the 802.1x supplicant and RADIUS server have computer certificates used in a TLS Handshake transaction for mutual authentication.

The EAP-TLS transaction begins when the client sends a standard 802.11 authentication request to the access point and gets back an EAP Request/Identity message specifying the EAP-TLS protocol.

1. The station replies with an EAP Response/Identity message containing its own ID.

2. The access point repackages this into a RADIUS Access Request and forwards it to a RADIUS server. From this point forward, the access point acts as a go-between and can be ignored.

3. The RADIUS server returns an EAP Request specifying EAP-TLS as the authentication mechanism.

4.The station returns an EAP Response containing a TLS Client-Hello message. This message contains the encryption algorithms supported by the client (called a cipher suite).

5. The RADIUS server replies with an EAP Request containing a TLS Server-Hello message with a session ID and those elements of the client’s cipher suite the server supports. This message also contains the server’s public key certificate and a request for the client to send its own public key certificate.

6.The station returns an EAP Response containing the following TLS messages: The client’s public key certificate, the client’s verification of the server’s public key certificate (digitally signed by the client), and an agreement to use one of the server’s cipher suite selections.

To use EAP-TLS, or any of the other protocols, you must also install one or more RADIUS servers to act as 802.1x Authentication servers. The RADIUS server must explicitly support EAP-TLS and be configured with the IP address or name of the access points. This prevents rogue servers from obtaining RADIUS credentials. The two machines share a password known as a RADIUS secret. This password should be long, strong and kept secure.

When creating a RADIUS client in Win2K IAS, be sure to select the appropriate Client-Vendor from the drop-down list. This loads a set of specific RADIUS settings supplied by the vendor for its access points. In some cases, you must install additional RADIUS settings using files obtained from the vendor.

RADIUS uses policies to control access. A policy can be applied to selected entities so, to distinguish your wireless policy from other RADIUS policies, configure the NAS-Port-Type attribute to hold “Wireless - IEEE 802.11” and “Wireless – Other.”

A RADIUS server can have multiple policies. Policies act like a set of screens used at a gravel pit. Rocks not stopped by the first screen fall through to the second screen. If your wireless stations refuse to work when configured for EAP-TLS, the RADIUS logs may indicate a policy restriction. Look for other RADIUS policies that might be interfering.

Once you’ve created the RADIUS policy, specify what a client must do to authenticate. These specifications take the form of a profile. In the case of wireless policies, the profile defines the required authentication and encryption methods. Select EAP-TLS.

Client Configuration
Now you need to configure your wireless stations. To configure a Windows XP client, for example, click the Authentication tab and specify Smart Card or Other Certificate. Click Configure to select the computer certificate issued by a Certification Authority (CA) trusted by the client. Otherwise, the client can’t validate the certificate and authentication will fail.

Remember to configure the client to use WEP for data encryption. EAP-TLS doesn’t replace WEP—it simply augments the authentication process. Because EAP-TLS dynamically assigns WEP cipher keys, be sure to check the option “The Key Is Provided For Me Automatically” or a similar option provided by your wireless NIC driver.

In the Advanced configuration, select the Smart Card or Other Certificate option. This adds EAP-TLS to the list of authentication mechanisms recognized by the client.

Once you’ve installed the necessary servers and made the required configurations, you’re ready to test the system. For the sake of diagnostics, it’s a good idea to enable Event Logging at the IAS server. Also for the sake of diagnostics, you should enable event logging at the access point. This often takes the form of a syslog, either stored in volatile memory at the access point or sent to a syslog server. Refer to your vendor’s documentation for details.

The icon representing the wireless connection in Network Connections should be lit up and enabled. You should be able to ping the IP address of the access point. If this doesn’t work, eject and reinsert the card to reinitialize the drivers. You should see syslog entries at the access point saying that the client has authenticated, then associated. The Event Log should have an IAS entry saying that the laptop (the name will end with a dollar sign) has successfully authenticated.

If you don’t get these results, look first for a problem with the configuration settings, then at the possibility that the certificates haven’t been issued correctly.

Protected EAP
PEAP is superior to EAP-TLS because it authenticates the user rather than the station. PEAP uses Microsoft’s Challenge Handshake Authentication Protocol, version 2 (MS-CHAPv2). The user enters a name and password when prompted by the wireless NIC driver.

A PEAP client is built into XP Service Pack 1. You can download a PEAP client for Win2K from the Microsoft download site. If you’re a Premier or Volume License client of Microsoft, you can get PEAP clients for Windows 98 and Me.

To protect the MS-CHAPv2 transaction, PEAP first creates a TLS session. This requires the RADIUS server to have a computer certificate but not the client, avoiding the necessity of a full-blown PKI deployment. You can obtain the TLS certificate for the RADIUS server from vendors such as VeriSign or Baltimore. Thawte (a VeriSign subsidiary) provides a 30-day certificate free, which you can use for testing.

A PEAP transaction begins as soon as a wireless station sends a standard 802.11 authentication request to an access point and gets an EAP Request/Identity as a reply. The authentication takes place in two phases.

In phase 1, the station uses the TLS Handshake Protocol to create an encrypted session with the RADIUS server. (Note that the session goes through the access point but doesn’t involve it.)

During the TLS establishment phase, the server may request a certificate from the client, but the client doesn’t need to provide one. If the client refuses to supply a certificate, the transaction proceeds to phase 2.

At the start of phase 2, the RADIUS server initiates a second EAP authentication with the station. This second EAP occurs within, and is protected by, the TLS session. The EAP session begins with a Request/Identity message that specifies an authentication method desired by the server. In the case of PEAP with Microsoft IAS, this method would be MS-CHAPv2, so the RADIUS server returns a random number as a challenge.

The user at the station is prompted to enter domain credentials. In XP, this occurs in a pop-up balloon from the network icon in the notification area. In the Win2K client, this occurs with a standard pop-up.

The user enters a name, password and domain. The password is hashed using MD4, and the password hash is used to encrypt the challenge. The encrypted challenge is returned to the server. Because the challenge and challenge response occur within the TLS session, they’re invisible to sniffers.

The RADIUS server uses information from a domain controller to validate the user’s credentials, then returns a RADIUS Accept message with the MPPE keys that will be used by the access point to encrypt the WEP keys.

Once the EAP-TLS transaction is complete, all subsequent communications between the client and the access point are protected by WEP. The dynamic keys are changed every so often to keep them from becoming stale.

Tunneling TLS
This protocol provides for more general authentication and encryption mechanisms than EAP-TLS or PEAP. Like PEAP, there’s no requirement for a client-side certificate. The TLS Handshake Protocol does the authentication, and the resultant TLS channel is used to encrypt the user authentication.

The difference in TTLS lies in the ability of the wireless station and the access point to negotiate an authentication protocol by exchanging Attribute-Value Pairs (AVPs). In PEAP, only MS-CHAPv2 authentication is supported. Using TTLS, any authentication method with an EAP designator can be used. Other than the exchange of AVPs, an EAP-TTLS transaction works similarly to PEAP.

Other Wireless Solutions
In addition to the options I’ve listed in this column, several enterprise-ready wireless solutions have recently hit the market. These products focus on wireless switching as well as enterprise management of security. Check out the Mobius line of products from Symbol Technologies, www.symbol.com, and a new startup called Aruba Wireless Networks, www.aruba-wireless.com.