EAP Methods

The E in EAP is both its greatest strength and greatest weakness. Extensibility allows a protocol to develop new features as new requirements present themselves. EAP has gone from a way to preserve PPP protocol numbers into the cornerstone of wireless LAN security because of its extensibility. Correctly deploying EAP can be difficult, however, since there can be a great number of questions to sort through to select the right protocol options. The key to EAP's flexibility is its status as a framework. New methods can be designed as new requirements arise, which enable the development of new methods for use in wireless LANs.

The topic of wireless LAN security protocols is a broad one, and this chapter draws the line at the detailed mechanics of how the protocols work on a bit-by-bit basis. A great deal of complexity will be described qualitatively, without the use of detailed packet diagrams.

Cryptographic Methods

Selecting an EAP method is usually driven by the type of back-end authentication system in use. Early EAP methods focused mainly on providing a channel to communicate with the authentication server. Newer methods designed for wireless networks enable communication with the authentication server, but also meet three major goals that are unique to wireless LANs:

Strong cryptographic protection of user credentials

By definition, wireless LAN media should be regarded as open. Any data sent over a wireless network must be protected if it is to remain secure. Most EAP methods designed for wireless LANs use TLS to provide cryptographic protection of credentials.

Mutual authentication

Early wireless LAN protocol design considered authentication to be something that users performed when required by APs. Falling AP prices have enabled attackers to deploy "rogue" APs to steal user credentials. Common sense dictates in addition to user authentication, client devices must be able to validate that they are connecting to a network that is what it appears to be.

Key derivation

WEP with manually-defined keys provides very little protection of frames on the radio link. Stronger security protocols need to use dynamic keys that are derived from an entropy pool. One of the side effects of providing strong cryptographic protection is that such protocols also generate a shared stream of cryptographically secure bits that can be used to distribute keys to link-layer security protocols.

LEAP

The first widely-used method for authenticating wireless networks was Cisco's proprietary Lightweight EAP (LEAP).[*] LEAP was a huge step forward from manual-key WEP, though it leaves a great deal to be desired. In essence, LEAP is two MS-CHAP version 1 exchanges. One authenticates the network to the user, and the second authenticates the user to the network. Dynamic keys are derived from the MS-CHAP exchanges.

[*] Some standards may refer to LEAP as "EAP-CiscoWireless."

Many of the worst security problems stem from the use of MS-CHAP version 1, which has numerous security problems, and is subject to dictionary attacks. Code to exploit LEAP's weaknesses is now widely available.

LEAP was an interim solution that had significant security benefits when compared to manually keyed WEP, but the use of the antiquated MS-CHAP at its core limited its useful life. Once other protocols became available, LEAP's purpose was extinguished. Cisco now recommends using PEAP or EAP-FAST.

Code 13: EAP-TLS

Transport Layer Security (TLS) was designed for use on links subject to eavesdropping. TLS is the standards-based successor to the Secure Socket Layer (SSL), the protocol that enabled secure web transactions. In many respects, the use case for wireless LANs is similar to the Internet. Data must be transmitted over a totally untrusted network with all manner of attackers. Establishing a trusted communication channel over an untrusted network is the purpose of TLS.

TLS provides mutual authentication through certificate exchange. The user is required to submit a digital certificate to the authentication server for validation, but the authentication server must also supply a certificate. By validating the server certificate against a list of trusted certificate authorities, the client can be assured that it is connecting to an network authorized by the certificate authority.

EAP-TLS was the first authentication method to meet all three goals for wireless networks. Certificates provide strong authentication of both the users to the network, and the network to users. Mutual authentication provides a strong guard against so-called "rogue" access points by enabling clients to determine that an AP has been configured by the right department, rather than an attacker who is intent only on stealing passwords. TLS also establishes a master secret that can be used to derive keys for link layer security protocols.

Though secure, EAP-TLS has seen only limited use. Any potential user of the wireless network must possess a digital certificate. Generating and distributing certificates while following processes to verify trust is a major challenge. Organizations that already had a public key infrastructure were able to use EAP-TLS easily; many organizations have shied away from building a PKI, and use an alternative method.

Code 21: EAP-TTLS and Code 25: EAP-PEAP

Practically speaking, the requirement for PKI was a major bar to the use of strong authentication on wireless LANs. PKIs are a significant undertaking in both technology and process. Most organizations found it desirable to re-use existing authentication systems, such as a Windows domain or Active Directory, LDAP directory, or Kerberos realm. Re-using existing accounts is much easier than creating a parallel authentication system. The two EAP methods intended to enable the use of so-called "legacy authentication methods" are Tunneled TLS (TTLS) and Protected EAP (PEAP).

Both TTLS and PEAP work in a similar fashion. In the first step of the protocol, they establish a TLS tunnel using routines similar to EAP-TLS. Digital certificates on the authentication server are used to validate that the network should be trusted before proceeding to the second step. In the second step, the TLS tunnel is used to encrypt an older authentication protocol that authenticates the user to the network. The first step is sometimes referred to as the "outer" authentication, since it is a tunnel that protects the second or "inner" authentication.

Certificates are still required, but only for the outer authentication. Reducing the number of certificates from hundreds or thousands down to a handful for authentication servers has made both TTLS and PEAP much more popular than EAP-TLS. Within an organization, the small number of certificates can be generated by a small certificate authority, rather than relying on expensive certificates signed by an external certificate authority.

The slight difference between TTLS and PEAP is in the way the inner authentication is handled. TTLS uses the encrypted channel to exchange attribute-value pairs (AVPs), while PEAP uses the encrypted channel to start a second EAP exchange inside of the tunnel. The use of AVPs makes TTLS much more flexible because AVPs can be used to run authentication methods that do not have corresponding EAP methods.

One minor advantage to the use of TTLS and PEAP is that the inner and outer authentications can use distinct usernames. Rather than revealing the username in unencrypted frames, both protocols can submit an anonymous username for the outer authentication, and only reveal the user's true identity through the encrypted channel. Not all client software supports the use of identity hiding.

Noncryptographic EAP Methods

Several EAP methods are not suitable for use directly on wireless networks without strong cryptographic protection. However, they may be useful as inner authentication methods with PEAP or TTLS.

Code 4: MD-5 Challenge

The MD-5 Challenge is used to implement the EAP analog of the CHAP protocol, specified in RFC 1994. Requests contain a challenge to the end user. For successful authentication, CHAP requires that the challenge be successfully encoded with a shared secret. All EAP implementations must support the MD-5 Challenge. It is not, however, widely supported on wireless networks because it does not provide dynamic keys on wireless networks.

Code 6: Generic Token Card

Token cards such as RSA's SecurID and Secure Computing's Safeword are popular with many institutions because they offer the security of "random" one-time passwords without the hassle of a one-time password (OTP) rollout. The Request contains the Generic Token Card information necessary for authentication. The Type-Data field of the request must be greater than zero bytes in length. In the Response, the Type-Data field is used to carry the information copied from the token card by the user. In both Request and Response packets, the Length field of the EAP packet is used to compute the length of the Type-Data request.

EAP-GTC was standardized along with EAP in RFC 2284. It allows the exchange of cleartext authentication credentials across the network. In addition to use with token cards, EAP-GTC is often used in practice as an EAP method for "username+password" authentication. If the existing user accounts are in a database that has one-way encrypted passwords (or compare-only passwords), EAP-GTC provides an EAP method that can validate users. Naturally, if EAP-GTC is used to transport reusable passwords, it must be used inside a tunnel for protection and server authentication.

Code 29: EAP-MSCHAP-V2

Microsoft CHAP version 2 (MS-CHAP-V2) was initially introduced with Windows 2000 and is documented in RFC 2759. It was designed to address the shortcomings of MS-CHAP by eliminating the weak encoding of passwords for older clients, providing mutual authentication, and improving keying and key generation.

MS-CHAP-V2 is widely supported by Microsoft clients, and is commonly supported and used as an inner authentication method with PEAP. MS-CHAP-V2 is the most common inner method used with Windows domains. When used as an EAP method, EAP-MSCHAP-V2 can be used with either TTLS or PEAP.

Code 18: EAP-SIM and Code 23: EAP-AKA

Two notable EAP methods working through the standards process are EAP-SIM and EAP-AKA, which can be used for authentication against mobile telephone databases. EAP-SIM provides an interface to the Subscriber Identity Module (SIM) database on GSM telephone networks. EAP-AKA is based on the authentication system in third-generation mobile telephone networks, called Authentication and Key Agreement (AKA).

EAP-SIM and EAP-AKA are useful for telecommunications companies that are interested in providing integrated billing with mobile telephone accounts. Rather than require that users generate new passwords to authenticate to data networks, they can use an existing smart chip and user account.

Other Inner Authentication Methods

TTLS is not restricted to using an EAP method for inner authentication. As a result, some older methods may be used with TTLS. For some networks, the user database is stored in such a way that there is no EAP method that provides a usable interface.

Password Authentication Protocol (PAP)

PAP was originally specified for use with PPP in RFC 1334. PAP transmits the username and password across the network unencrypted. When used with wireless networks, PAP should not be used directly, but only as an inner method inside of TTLS to ensure that the password is not revealed.

PAP can be used with any type of authentication system. Network logons can be validated against a network operating systems. Token card servers can validate cleartext token codes. PAP is also useful for one-way encrypted passwords that can be compared, but not read. One-way encrypted passwords are used in Unix /etc/passwd files, as well as most LDAP directories. Kerberos systems also store passwords with one-way encryption.

Challenge Handshake Authentication Protocol (CHAP)

Like PAP, CHAP was originally designed for use with PPP, and is specified in RFC 1994. In CHAP, the authentication server challenges the client, and the client proves that it is in possession of the shared secret by successfully responding to the challenge.

CHAP was originally designed to avoid sending secrets, such as passwords, in the clear. The downside of CHAP is that it requires the password in cleartext at both ends of the link. On the server end, the password must either be stored in the clear, or reversibly encrypted to enable server software to recover the cleartext.

CHAP is not typically used in wireless environments unless a large user database already exists and is using CHAP.

MS-CHAP, version 1

MS-CHAP was designed by Microsoft to offer similar functionality to CHAP, but with enhanced functionality for Windows systems. It is proprietary to Microsoft, but documented in RFC 2433. Unlike CHAP, MS-CHAP does not require that the shared secret be stored in cleartext at both ends of the link. Instead of using the cleartext password as the shared secret, MS-CHAP uses the MD4 hash of the user password.

MS-CHAP is useful in environments where Microsoft authentication databases are used. However, there are particular issues with MS-CHAP that make it undesirable from a security point of view; it should only be used by network managers who must support very old Microsoft clients, such as Windows 95/98. MS-CHAP is not an EAP method, and is only supported by TTLS.

EAP Method Filtering

Some EAP methods are stronger than others. In the interests of "security," some equipment vendors filter EAP methods in the authenticator. EAP-MD5 is often selected as a target for EAP type filtering because it is much weaker than TLS-based methods.

EAP method filtering is not necessary, and has the potential to get in the way of good security practice. Many filters only allow TLS-based tunnel methods (types 13, 21, and 25). If a new EAP method is defined, many EAP method filter implementations will block it by default. Allowing configurable EAP method filters would be one potential solution, but I do not know of any such implementations.

In practice, EAP method filters are not that valuable from a security perspective. Authentication servers can enforce the use of strong authentication by refusing any requests using weak methods. In any case, the lack of keying material may prevent network connection. If no keys can be derived from the authentication, many APs will void the authentication, kick the client off, and start over. EAP-MD5 authentications will start, succeed, fail to key, and be restarted when the AP dissassociates the client.

Due in part to these problems, EAP method filtering is not allowed by the EAP specification. Section 2.3 of RFC 3748 mandates that authenticators must forward any EAP methods to the authentication server for processing.