EAP Authentication Types

LEAP has become the most popular form of EAP currently in use because of its relatively simple deployment requirements and the popularity of the Cisco Aironet product line. It runs on most popular operating systems and hardware platforms and is supported by nearly all RADIUS vendors. Because LEAP uses password-only authentication, its security level is determined by the strength of the passwords employed. Over the last couple of years, Cisco has begun moving toward a new standard called Protected EAP (PEAP).

A segment of the keying data created during the TLS session initiation for that channel is sent to the authenticator and the supplicant, which already knows the TLS-established secret key, and the authenticator uses that key for WEP encryption. Because the supplicant wants to talk to the authenticator, the authentication server encrypted channel configured by TLS between the authentication server and the supplicant is not used.

Certificates are used to authenticate the authentication server to the supplicant in EAP-TLS with an option to authenticate the supplicant to the authentication server. The process is started when the authentication server sends its digital certificate to the supplicant. In one-way authentication, a server sends its certificate to a browser to prove its identity. SSL version 3 is supported by all current versions of Web browsers and is very similar to TLS. For many people, all that matters is that the results of SSL or TLS are the same—an encrypted session between the browser and the Web server— and both methods start with the same authentication phase. As discussed earlier, EAP-TLS administrators should be more interested in using mutual authentication than one-way authentication because it protects the network against man-in-the-middle attacks.

Because both wireless clients and access points are strongly authenticated using digital certificates, the deployment of certificate authorities has become much easier and more cost effective. The advantages of EAP-TLS make it a preferred authentication method for WLANs. The client can be reauthenticated and rekeyed as often as needed without inconveniencing the end user as a result of per-session WEP keys. Although EAP-TLS has had some software bug implementation problems, it has been tested extensively without being broken or revealing any significant security flaws in the protocol itself; however, it should be noted that the username is passed from client to server in a TLS exchange before certificates are exchanged, and it is possible to observe the username's passive packet analysis. If remote access connections are being made in the Windows environment and SmartCards are being used, EAP-TLS authentication should be mandatory.

The response to the server is validated based on its knowledge of the password. Unfortunately, EAP-MD5 allows an eavesdropper to obtain both the challenge and the encrypted response, making it possible to conduct a dictionary attack using the same algorithm that was used to obtain the user's password. Also, because MD5 authenticates only the supplicant and does nothing to authenticate the authentication server, a rogue RADIUS server could be added to the WLAN by an attacker to obtain the login credentials of a legitimate user.

One other security risk is that MD5 does not use per-session WEP keys. Immediately after authentication, communication between the client and the access point is either not encrypted or is encrypted with a static WEP key, which allows eavesdropping to occur on data communications over a WLAN because static WEP can be broken. Many companies have chosen not to use MD5 as an authentication method because of its inherent vulnerabilities when used in a WLAN. Of particular concern, MD5 lacks persession WEP keys, one-way authentication, and challenge passwords. These shortcomings make use of MD5 a risky proposition.

Several weaknesses in EAP were identified shortly after it was released. While using EAP, it was found that the initial identity request and corresponding response is sent in cleartext, so an attacker capturing and analyzing packets could obtain user identities for use in later attacks. There is no support in EAP for fast reconnections when roaming. This creates a problem when a client is trying to associate with a new access point while network traffic is flowing. EAP does not include packet management, so individual vendors are required to handle packet fragments and reassembly.

The administrator must configure PEAP as an EAP type for a given connection policy as managed through a RADIUS server. PEAP must be supported by the client software and, in some cases, the firmware. Several older methods of user authentication such as MS-CHAPv2 are generally used as secure certificate-based authentication. They do not require the added management overhead necessary to implement and manage certificates. Both EAP-TTLS and PEAP were designed to use older authentication methods while maintaining the strong cryptographic foundation of TLS.

Both TTLS and PEAP are two-stage protocols that establish security in stage one and then exchange authentication in stage two. Both protocols establish a TLS tunnel in stage one and authenticate the authentication server to the client with a certificate. Although TTLS and PEAP still use certificates to authenticate the wireless network to the user, only server-side certificates are required. This results in a much more manageable system than that provided by a complete PKI certificate-based authentication system. In stage two, a secure tunnel is established and the client authentication credentials are exchanged. A TLS tunnel is used by PEAP to protect a second EAP exchange. The authentication must be performed using an EAP-defined protocol. Microsoft and Cisco both support PEAP. Client software is built into Microsoft's operating systems. Third-party add-on software is now available.

TTLS has a much larger market presence and acceptance than PEAP, resulting in much broader RADIUS support for TTLS than PEAP. Cisco and Microsoft's support of PEAP may drive expanded PEAP support in RADIUS. Both Cisco's Aironet Client Utility (ACU) and Windows XP with Service Pack 1 support PEAP. Currently, Microsoft provides native support for PEAP in Windows operating systems such as Windows XP and Windows.NET. Cisco's development of cross-platform clients may also assist in driving the growth of wireless PEAP implementations and applications.

This section has provided a brief overview on WEP's usage and its inherent insecurity. TKIP and MIC were discussed as a solution to WEP's weaknesses. The different types of EAPs were reviewed in detail to provide a better understanding of how each protocol performs authentication. Advantages of dynamic key management and implementation methodologies were compared, along with the EAP types, including EAP-MD5, EAP-TLS, LEAP, EAP-TTLS, and PEAP. We next turn our attention to the use of Virtual Private Networks (VPNs) in a WLAN environment.