Examining 802.11i and WPA

Products using the new Wi-Fi Protected Access Technology are here, with 802.11i-compliant products coming soon. We help you decide which one is best for your organization.

March 27, 2004

11 Min Read
Network Computing logo

As a standards body, the IEEE 802.11i task group wasn't under the same market pressures as the vendor-driven Wi-Fi Alliance. After nearly three years of debate, the 802.11i committee is putting the finishing touches on its security standard, the Robust Security Network. RSN requires wireless clients and APs to have capabilities most existing devices don't have, including higher processing power and support for intensive encryption algorithms. There is also a transitional spec--conveniently called Transitional Security Network (TSN)--that lets RSN and older WEP systems operate in parallel in the same WLAN. But your wireless network won't be fully secure until it's all RSN.

RSN and WPA have a lot in common. They use the same security architecture for upper-level authentication, key distribution and key renewal. WPA, though, is built around TKIP (Temporal Key Integrity Protocol), which is available as a firmware upgrade to most legacy hardware. RSN is more comprehensive and includes support for AES (Advanced Encryption Standard), which is available only on the latest WLAN hardware.

We evaluated WPA in our Syracuse University Real-World Labs for integrity, confidentiality and authentication criteria (see "Meanwhile, Back at the Lab,").WPA, expressed as a formula, looks like this:

WPA = {802.1X + EAP + TKIP + MIC + (RADIUS*X)}If WPA-PSK, X=0; ELSE X=1

WPA uses existing technology such as IEEE 802.1x, EAP, TKIP and RADIUS. Its authentication is based on the 802.1x authentication protocol that was developed for wired networks, as well as EAP (Extensible Authentication Protocol). EAP lets you use a variety of algorithms for authenticating the client with a RADIUS server.The confidentiality and integrity pieces are based on TKIP, rather than WEP's weak key management, but WEP's RC4 cipher-stream algorithm is used for data encryption. TKIP uses a 48-bit initialization vector (versus the 24-bit initialization vector in WEP) with sequencing rules, which protects against key reuse and replay attacks. It also has a per-packet, key-mixing function that protects against WEP weak key attacks and a keyed cryptographic checksum that prevents packet forgery attacks. This last feature is based on the new MIC (Message Integrity Code), a 64-bit cryptographic tag that uses minimal CPU.

WPA operates in two modes: PSK (Preshared Key) and Enterprise. WPA-PSK requires a shared pass phrase to establish the wireless network. It's easy to install but not as robust as the Enterprise mode, which uses a key hierarchy to derive pair and group keys for authentication. Even though TKIP uses WEP's RC4 block cipher, WPA is more robust. The Wi-Fi Alliance says the system was designed and scrutinized by renowned cryptographers.

The default confidentiality mode for IEEE 802.11i/ RSN, meanwhile, is based on the AES block cipher. The security protocol built around AES is called Counter Mode-CBC MAC Protocol, or CCMP. AES is to CCMP as RC4 is to TKIP. The biggest difference between RSN/ CCMP and WPA/TKIP is at the lower layers where data is encrypted and decrypted: TKIP uses four temporal keys, whereas AES uses only three. Key management is the same for both protocols.

In most cases, you must upgrade the firmware or software in your APs to support WPA. Going RSN requires new hardware that supports AES. If your AP was purchased after the fourth quarter of 2003, you'll probably need to upgrade your firmware or software for full 802.11i compliance. Most new enterprise wireless APs have the hardware processing power for 802.11i/RSN, but the firmware and software won't be available until after the 802.11i standard is ratified.

To enable WPA on your wireless client devices, you must upgrade the utility software or driver for WPA, as long as the device is made for the upgrade. It's not so simple, though, to make your clients RSN-capable. RSN's processor-intensive AES encryption is too much for most wireless clients, so existing laptops and handhelds must be replaced with newer devices that support RSN.Radiating with RADIUS

Your APs need RADIUS authentication to work with WPA or RSN. And like the clients, they must support whichever encryption is used, like TKIP or AES, which means a firmware upgrade. They also must support fast reauthentication after a session time-out or drop, namely for real-time apps like voice over WLANs. WLAN RADIUS servers are specifically designed for APs. Companies like Funk Software, Meetinghouse Data Communications and Interlink sell WLAN versions of their RADIUS servers.

You can use your wired RADIUS server for the WLAN if it supports the EAP algorithms you'll use. If not, a WLAN RADIUS can access your legacy RADIUS server as a proxy. The WLAN RADIUS server works like this: It first verifies the client's credentials against a user name-password set or certificate or token ID. Then it enables the AP and client to dynamically generate a set of keys for each session. WPA requires the EAP's TLS (Transport Layer Security), whereas IEEE's 802.11i doesn't specify any specific EAP types. The EAP type you choose depends on the client's application needs and your network architecture.

Your laptops and handhelds also need supplicants--802.1x clients that provide 802.1x/EAP services--for both WPA and RSN WLAN security. Funk and Meetinghouse offer these add-ons for various client OSs, and Cisco includes a free 802.1x supplicant with its Aironet Client Utility. Microsoft packages one with its Zero Config utility in Windows XP; a free supplicant is downloadable for Windows 2000. The catch, however, is that these prepackaged supplicants don't typically support all EAP types.The easiest WPA model to deploy is WPA-PSK for the small or home office. There's no need for a RADIUS server, and the PSK passphrase is used by the RC4 cipher block to encrypt the packet and facilitate MIC. That may be sufficient for most SOHO environments, but it's best to have passphrases with more than 20 characters.

Enabling WPA-PSK is a walk in the park. First, check if your wireless devices are WPA-compatible, then upgrade their firmware or software as needed. A good place to check for WPA compliance is the Certified Product Listing from the Wi-Fi Alliance. The Windows XP embedded supplicant works for the SOHO environment, but you must download a security update (see support.microsoft.com/?kbid=815485). You can get more information on WPA-PSK deployment here.Enterprises can go WPA-802.1x with RADIUS servers and PC client supplicants. Most enterprises choose RADIUS over WPA-PSK because PSK requires more administrative overhead and can be vulnerable. Employing RADIUS requires a thorough examination of the merits of alternative EAP types.

Here and Now

If your company's handheld devices are used to conduct critical transactions--like in the health-care, manufacturing and logistics industries--you'll have to deploy WPA because existing handhelds don't support RSN's hefty AES. Until 802.11i is finalized and its features for real-time wireless apps like voice over WLAN are available, WPA is the next best thing for true wireless security.

Frank Robinson is a systems associate at Syracuse University. Write to him at [email protected]. How do the 802.11i and WPA specs stack up? To find out, we tested some WPA systems in our Syracuse University Real-World Labs.

Once you've decided on a RADIUS server and established a security context for your WPA system, you must integrate the server with your organization's identity database. To get a feel for what's involved, we set up Meetinghouse's Aegis WLAN Security client and server products. To establish the security context, we obtained a certificate for the server from the enterprise root CA (certificate authority).To enable WPA with the Aegis server, we had to include the EAP module (PEAP) in the authentication, authorization and accounting policy and configure the EAP module's authentication type (MS-CHAPv2).

Like most RADIUS servers, Aegis can enforce access control with check attributes, which specify that a client can access the WLAN through certain APs. The server uses the reply attributes to give user-specific parameters to the AP. These attributes, such as inactivity time-out and session time-out, work only if the AP device supports them. In our tests, Proxim's AP-600 worked well with the WPA-based Aegis setup.

To ensure that the client devices could access the secure WPA infrastructure, we included the CA issuing the server certificate in the trusted-root CA store of the client. So when the client authenticated, the server's identity was verified first and then the client's identity, with PAP, CHAP or MS-CHAPv2.

We also ran Funk's Odyssey RADIUS server to enable a PDA. You provision it much the same way as the Aegis RADIUS server, except in how you define your EAP type and point to server certificates. In the Odyssey server, all EAP modules are included by default and only need to be enabled. Odyssey's management interface defines a single server certificate for TLS, TTLS and PEAP, whereas Aegis lets you define multiple certificates through its console.

We set up a secure channel through a tunneled encryption mechanism using EAP's TTLS, and configured our Pocket PC PDA using the Odyssey Client for Pocket PC configuration manager. The Odyssey server can authenticate users only against an NT domain or Active Directory, so the user profile requires that you use the domain name with the user name.Deploying WPA requires a thorough audit of the business need the network will address and the applications that the WLAN will support. Roaming between access points wasn't easy with WPA--we often had to reauthenticate manually. WPA's lack of support for reauthentication is a constraint for real-time applications, especially when clients regularly roam between access points.

During our test run of WPA, we had multiple sensors running in the lab as part of a wireless security monitors review for NETWORK COMPUTING (see ID# 1504f2). We identified the WPA clients and access points as protected/encrypted entities. But when we launched denial-of-service attacks with a deauthentication packet, the WPA devices were susceptible.

Meanwhile, the closest we could get to 802.11i deployment was enabling AES instead of TKIP in the encryption process on the AP. We only used clients that had enough CPU power to support AES; handhelds couldn't be secured because they didn't have AES support. There was no difference in how the devices performed with AES. And when you transition from WPA to 802.11i, there shouldn't be much of a difference in session setup, but reauthentication and roaming will perform better. A RADIUS server customized for wireless LANs is designed on the same core architecture as a wired RADIUS server, but certain authentication protocols native to the original RADIUS standard need not be implemented for wireless. Protocols like SLIP, PPTP and L2TP are not suave enough for the wireless environment. Instead, WLAN RADIUS places an emphasis EAP.

Most WLAN RADIUS servers can be installed on Unix or Windows platforms. The server and the administration/configuration programs are independent. Interlink's Secure.XS and Meetinghouse's Aegis server use Java applications to administer the server. The server platform governs the breadth of authentication stores with which the wireless devices can interact. Some of the common ID stores are local database or flat ASCII file, SQL database, LDAP servers, Windows NT Domain, Windows Active Directory, Unix password/user files and/or token-based stores.

A RADIUS server can perform a look-up authentication or a log-in authentication. In the look-up mode, the server authenticates the user against the ID store and returns user-specific attributes from the ID store with the access-accept packet. In the log-in mode, the user's credentials are used to log in to the authentication store/system. If the credentials are validated, the user receives an access-accept packet. However, the user-specific attributes in the authentication stores cannot be returned to the client in login mode, rather a default reply attribute applied to all users is returned. This is an integration issue primarily with those ID stores that encrypt data-the predominant challenge is interfacing with Windows Active Directory and similar LDAP servers.Proxy support is an important feature in WLAN RADIUS servers especially if the network has an existing AAA server. Proxy support lets the server maintain accounting information and user data in a database that also holds information pertaining to conventional RADIUS usage, such as dial-up, VPN and firewall-access data. The challenge in proxy support is to account for tunneling user access, which by virtue of design is hidden.

The host of EAP authentication types is a distinguishing factor in RADIUS servers. By default, all servers support mutual authentication through tunneled protocols like TTLS, PEAP and TLS. They differ in the type of internal authentication mechanism they can support, which is highly dependent on the ID stores they authenticate against. For example Funk's Odyssey server supports TTLS with MS-CHAP-v2 as its internal authentication mechanism because it is closely integrated with Active Directory.

A WLAN RADIUS server defines user-specific check and reply attributes, such as NAS-IP address, session time-out, idle time-out and framed IP address. A WLAN RADIUS server also defines attributes to groups and realms that are later applied on users defined in its local database. RADIUS servers like Interlink's Secure.XS also can restrict a user's access based on his or her organization role. Some servers can restrict concurrent logons by keeping track of the sessions provisioned by the server.

WLAN RADIUS servers are carving their own niche in the secure access market. However, don't expect the robustness of a conventional RADIUS server in these access-specific products.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights