Bill wraps up his three-part series on building a wireless infrastructure by discussing security protocols.
- By Bill Boswell
This is the final installment of a three-part series on deploying wireless
stations in a Windows network. This part covers the 802.1x dynamic key
exchange protocol and the two primary mechanisms used by Windows to support
802.1x: EAP-TLS and PEAP. These two mechanisms, and nearly all others
designed to protect wireless transactions, depend on setting up a secure
tunnel using Secure Session Layer/Transport Layer Security (SSL/TLS).
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
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
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
|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
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 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.
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
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.
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.