EAP-TTLS extends EAP-TLS to allow for one-way TLS authentication in addition to mutual TLS authentication. When one-way authentication is used, the AS is authenticated to the STA in a TLS handshake, which also creates an encrypted tunnel between the STA and AS. The tunnel is then used to protect a second authentication transaction in which the STA is authenticated to the AS. In EAP-TTLS, this second transaction is called an inner application and occurs in what are termed InnerApplication messages. These messages consist of a series of attribute-value pairs (AVP) that describe the inner application and specify the standard protocols and algorithms that support it. The AVP format is compatible with RADIUS, thereby enabling easy integration with existing authentication protocols that RADIUS supports. The AVP format is extensible, allowing new inner applications and corresponding AVPs to be defined as needed. Currently supported inner applications include EAP methods, CHAP,80 and PAP. When the inner application is another EAP method, it is referred to as the inner EAP method. The use of EAP-TTLS is analogous to popular e-commerce Web sites that prompt for a username and password. The client computer first uses TLS to validate the Web server’s certificate and establish an encrypted session with the server. At that point, passwords sent to the Web server are encrypted and therefore protected from eavesdropping. EAP-TTLS operates in a similar manner; the STA validates the AS’s certificate and uses the resulting TLS session to transfer user credentials securely.
Figure 6-2 shows a hypothetical WLAN that uses the EAP-TTLS method for authentication. The configuration is identical to the EAP-TLS example in Figure 6-1, but in this case a certificate is present on the AS only.
80 EAP-TTLS also supports the Microsoft variants of CHAP, namely MS-CHAP and MS-CHAPv2. CHAP and MS-CHAP are considered insecure, but MS-CHAPv2 provides adequate security for medium assurance applications.
Figure 6-2. Illustration of EAP-TTLS Environment
An advantage of EAP-TTLS relative to EAP-TLS is that it can support legacy authentication methods, using them as the inner authentication method. For example, if an organization has mature security processes and a large investment in an existing identity management system based on passwords, tokens, or biometrics, then it might make sense to leverage that system for its WLANs. It might appear that eliminating the requirement for certificates on STAs (the clients) greatly reduces the administrative complexity of the required supporting PKI; installing certificates on a small number of ASs is
considerably easier than installing them on hundreds or thousands of computers or smart cards. However, the root certificate must be delivered securely to every client to prevent man-in-the-middle attacks. The TLS tunnel protects the inner application from several attack types, including replay attacks and dictionary attacks. Unfortunately, it does not offer strong assurance against man-in-the-middle attacks. A shortcoming of EAP-TTLS is that it is only as strong as the inner application authentication method that occurs within the TLS tunnel. For instance, if EAP-TTLS is used with a legacy system that allows weak passwords, then that implementation of EAP-TTLS is weak, which in turn means the IEEE 802.1X port- based access control that relies on that implementation of EAP-TTLS is weak. In a cascading fashion, the strength of nearly all elements’ RSN protections is rooted in the strength of the EAP-TTLS inner
application to authenticate the STA, which is left unspecified. Therefore, organizations that implement EAP-TTLS should carefully consider the risks associated with any candidate method before deploying it. 6.1.3.3 PEAP
PEAP is the product of a joint development effort by engineers from Microsoft, Cisco Systems, and Extundo. PEAP’s characteristics are very similar to EAP-TTLS. Like EAP-TTLS, PEAP uses certificates and leverages TLS only to verify the AS’s identity to the STA and establish a secure communications channel to protect the transaction in which the STA authenticates to the AS. As with EAP-TTLS, no client certificates are required; however, provisioning the root certificate on each and every client is a mandatory security requirement.
The main difference between EAP-TTLS and PEAP is that PEAP’s tunneled authentication transaction is another EAP method rather than an exchange of AVPs. These tunneled EAP methods, also called inner EAP methods, might be an RFC 3748 method or a more recently developed EAP method. In practice, this distinction usually is not important because both EAP-TTLS and PEAP can run on any network topology
or protocol, are compatible with RADIUS, and can interoperate with any AP, none of which require method-specific code.
Given the similarities between EAP-TTLS and PEAP, it is possible that one will emerge as a de facto standard while the other becomes superfluous, but it is unclear which is more likely to become the standard at this time. A number of vendors are implementing EAP-TTLS in their WLAN products, and EAP-TTLS client software is available for most major operating systems (e.g., Linux, Mac OS, Microsoft Windows). PEAP has strong support from both Microsoft and Cisco Systems, which could encourage other vendors to implement PEAP in their solutions. In addition, Microsoft Windows XP provides native support for PEAP, but not EAP-TTLS. Organizations that require EAP-TTLS for Windows XP STAs need to procure third-party software. Also, the Windows version of PEAP supports MS-CHAPv2 only, which currently limits its use to authentication with Microsoft domains or Active Directory.
Organizations that need PEAP to interoperate with third-party ASs need to procure compatible third-party PEAP client software. Unfortunately, there are different non-interoperable implementations of PEAP, so organizations should take care that their server and client versions are compatible. Both versions should also fulfill the organization’s security requirements.
New industry developments could change the relative merits of each method. Neither EAP-TTLS nor PEAP has been approved as an IETF standard; EAP-TTLS is defined in an Internet-Draft, but the PEAP Internet Draft has expired. Given the rapid changes in this area, organizations are encouraged to obtain the latest information before selecting one of these methods.