Generic Token Card (GTC)

The GTC method is used for hardware token schemes that require user input. The EAP Request contains a displayable message, and the EAP Response contains the token-generated information needed for authentication. Like MD5-Challenge and OTP, GTC does not support any of the required WLAN security claims, but could be used if it were tunneled within another method that can support the required claims.

6.1.3

TLS-Based EAP Methods

The EAP methods defined in RFC 3748 have a number of serious security shortcomings; one of the most significant is that they do not generate key material. Without key material, the WLAN software on the STA and AP cannot apply protections to the traffic between STA and AP, as required for WLAN security. Consequently, IEEE 802.11 RSN solutions must deploy EAP methods other than those defined in RFC 3748 for the networks to be operational, regardless of the level of security desired. RFC 3748 states that due to the complexity of developing key generation algorithms, EAP methods should be based on well-established and analyzed key establishment and generation techniques. In practice, this

recommendation limits potential methods to those based on the following two key establishment and generation protocols:

+ Internet Key Exchange (IKE),72 _{which is most commonly used with Internet Protocol Security} (IPsec), a standard for virtual private networking

+ Transport Layer Security (TLS),73 _{a revision of Secure Sockets Layer (SSL), which is most} commonly used to secure Web site communications.

Both IKE and TLS can use public key certificates for authentication and secure transfer of key material; both also support authentication via pre-shared keys.74 _{However, TLS has emerged as the dominant} protocol for EAP methods that support IEEE 802.11 RSNs. TLS is designed either to authenticate a server to a client or to mutually authenticate the client and server to each other. For a device to be authenticated using TLS, it must host a public key certificate or be provisioned with a pre-shared key. In an IEEE 802.11 RSN context, if TLS using certificates is used only to authenticate the AS and generate key material, then only the AS must possess a certificate. In addition, the STA needs to have a copy of the AS’s certificate in order to authenticate the AS. In this scenario, the AS must authenticate the STA using one or more additional EAP methods tunneled within the TLS session. However, if TLS with certificates is used for mutual authentication, then both the STA and the AS must have certificates. Mutual TLS authentication generally is more secure than one-way TLS authentication coupled with one or more additional EAP methods.

The four most commonly used TLS-based EAP methods are as follows:

72 _{For more information on IKE, see RFC 2409, The Internet Key Exchange (IKE), at http://www.ietf.org/rfc/rfc2409.txt.} 73 _{For more information on TLS, see RFC 2246, The TLS Protocol, Version 1.0, at http://www.ietf.org/rfc/rfc2246.txt.}

Another good source of information is NIST SP 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations, available at http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf.

74 _{IKE has always included authentication using pre-shared secret keys. The TLS Working Group recently adopted RFC 4279,}

+ EAP-TLS75

+ EAP Tunneled TLS (EAP-TTLS)76 + Protected EAP (PEAP)77

+ EAP Flexible Authentication via Secure Tunneling (EAP-FAST).78 These methods are described in Sections 6.1.3.1 through 6.1.3.4.

6.1.3.1 EAP-TLS

EAP-TLS is defined in RFC 2716, which was published in October 1999. EAP-TLS is considered the most secure of the widely supported EAP methods, because it allows strong mutual cryptographic authentication of both STA and AS using public key certificates. To enable mutual authentication, each STA must obtain and host its own unique certificate. To provide each STA with its own certificate, organizations should maintain a public key infrastructure (PKI). Ideally, the certificate should be stored on a smart card or other device that can be removed from the STA, but certificates can also be stored on a STA’s hard disk or firmware. Use of the certificate should force the user to enter a personal identification number (PIN), password, or passphrase. Otherwise, theft of the STA or card may be all that is needed to authenticate to the WLAN.

Establishing and maintaining a PKI and a smart card infrastructure are not simple endeavors for most organizations. Implemented properly, a PKI involves a certificate policy and practice statement, certificate and registration authorities, and the maintenance of certificate revocation lists, which are needed for denying access when users’ devices are stolen or users no longer have a business need to access the network.79 _{Accordingly, EAP-TLS might be viable only for organizations that already have a} robust PKI in place or are planning one as part of an enterprise identity management solution. Another concern with using EAP-TLS is that its authentication process involves more steps than other methods, so its authentication transactions are slower. This can be problematic in environments in which users are highly mobile, because users might need to re-authenticate frequently and could be frustrated if performance suffers as a result.

Figure 6-1 shows a hypothetical WLAN that uses the EAP-TLS method for authentication. Certificates are located on all of the STAs and the AS. In an infrastructure with several thousand STAs and only several ASs, the need for client certificates greatly increases the level of PKI support required.

75 _{For more information on EAP-TLS, see RFC 2716, PPP EAP TLS Authentication Protocol, at} http://www.ietf.org/rfc/rfc2716.txt.

76 _{For more information on EAP-TTLS, see the draft proposed standard, EAP Tunneled TLS Authentication Protocol Version}

1, dated February 2005, at http://www.ietf.org/internet-drafts/draft-funk-eap-ttls-v1-xx.txt.

77 _{At the current time, PEAP is not standardized in an IETF RFC or Internet Draft.}

78 _{For more information on EAP-FAST, see the draft proposed standard, EAP Flexible Authentication via Secure Tunneling}

(EAP-FAST), dated April 25, 2005, at http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-xx.txt.

79 _{PKI implementations require a considerable investment in time and resources. It is outside the scope of this document to} discuss PKI in detail. See NIST SP 800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, for more information; it is available at http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf. Another document that might be helpful is The DoD Public Key Infrastructure and Public Key-Enabling Frequently Asked Questions. Although the document focuses on the Department of Defense PKI, its descriptions of PKI components are applicable to other

Figure 6-1. Illustration of EAP-TLS Environment

Several WLAN vendors support EAP-TLS in their STA software. Microsoft also supports a proprietary version of EAP-TLS in its Windows XP operating system.