PPPEXT Working Group Paul Funk Internet-Draft Funk Software, Inc. Category: Standards Track Simon Blake-Wilson Basic Commerce & Industries, Inc. July 2004 EAP Tunneled TLS Authentication Protocol (EAP-TTLS) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001-2004). All Rights Reserved. Abstract EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS. The authentication of Internet-Draft April 2004 the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other cryptographic attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake. This document describes two versions of EAP-TTLS - version 0 and version 1. Most of the document concerns EAP-TTLS v0, a form of the protocol that has been implemented by multiple vendors. Section 11 defines EAP-TTLS v1, an enhanced version of the protocol that utilizes the TLS extensions mechanism to allow authentications to occur within, rather than after, the TLS handshake. The TLS extension that is defined is believed to useful in its own right, and may be used in other contexts in addition to EAP-TTLS v1. Table of Contents 1. Introduction......................................................3 2. Motivation........................................................4 3. Terminology.......................................................6 4. Architectural Model...............................................8 4.1 Carrier Protocols.............................................9 4.2 Security Relationships.......................................10 4.3 Messaging....................................................10 4.4 Resulting Security...........................................11 5. Protocol Layering Model..........................................11 6. EAP-TTLS version 0 Overview......................................12 6.1 Phase 1: Handshake...........................................13 6.2 Phase 2: Tunnel..............................................14 6.3 Piggybacking.................................................14 6.4 Session Resumption...........................................15 6.4.1 TTLS Server Guidelines for Session Resumption............16 7. Generating Keying Material.......................................16 8. EAP-TTLS Encoding................................................17 8.1 EAP-TTLS Start Packet........................................17 8.2 EAP-TTLS Packets with No Data................................18 9. Encapsulation of AVPs within the TLS Record Layer................18 9.1 AVP Format...................................................19 9.2 AVP Sequences................................................20 9.3 Guidelines for Maximum Compatibility with AAA Servers........20 10. Tunneled Authentication..........................................20 10.1 Implicit challenge...........................................21 10.2 Tunneled Authentication Protocols............................21 10.2.1 EAP ......................................................22 Paul Funk expires January 2005 [Page 2] Internet-Draft April 2004 10.2.2 CHAP .....................................................23 10.2.3 MS-CHAP..................................................23 10.2.4 MS-CHAP-V2...............................................24 10.2.5 PAP ......................................................25 10.3 Performing Multiple Authentications..........................26 11. EAP-TTLS Version 1...............................................27 11.1 EAP-TTLS v1 Introduction.....................................27 11.2 Intentions Beyond EAP-TTLS...................................28 11.3 The InnerApplication Extension to TLS........................28 11.3.1 TLS/IA Overview..........................................29 11.3.2 Message Exchange.........................................31 11.3.3 Master Key Permutation...................................31 11.3.4 Session Resumption.......................................33 11.3.5 Error Termination........................................33 11.3.6 Application Session Key Material.........................33 11.3.7 Computing Verification Data..............................34 11.3.8 Attribute-Value Pairs (AVPs).............................36 11.3.9 TLS/IA Messages..........................................36 11.3.10 The InnerApplication Extension...........................37 11.3.11 The PhaseFinished Handshake Message......................37 11.3.12 The ApplicationPayload Handshake Message.................37 11.3.13 The InnerApplicationFailure Alert........................38 11.4 Binding of TLS/IA to EAP-TTLS v1.............................38 11.4.1 Flags Octet..............................................38 11.4.2 Version Negotiation......................................39 11.4.3 Acknowledgement Packets..................................39 11.4.4 Generating Keying Material...............................40 12. Discussion of Certificates and PKI...............................40 13. Message Sequences................................................42 13.1 Successful authentication via tunneled CHAP..................42 13.2 Successful authentication via tunneled EAP/MD5-Challenge.....44 13.3 Successful session resumption................................46 14. Security Considerations..........................................47 15. Changes since previous drafts....................................49 16. References.......................................................50 17. Authors' Addresses...............................................51 18. Full Copyright Statement.........................................51 1. Introduction Extensible Authentication Protocol (EAP) [2] defines a standard message exchange that allows a server to authenticate a client based on an authentication protocol agreed upon by both parties. EAP may be extended with additional authentication protocols by registering such protocols with IANA or by defining vendor specific protocols. Transport Layer Security (TLS) [3] is an authentication protocol that provides for client authentication of a server or mutual authentication of client and server, as well as secure ciphersuite negotiation and key exchange between the parties. TLS has been Paul Funk expires January 2005 [Page 3] Internet-Draft April 2004 defined as an authentication protocol for use within EAP (EAP-TLS) [1]. Other authentication protocols are also widely deployed. These are typically password-based protocols, and there is a large installed base of support for these protocols in the form of credential databases that may be accessed by RADIUS, Diameter or other AAA servers. These include non-EAP protocols such as PAP, CHAP, MS-CHAP and MS-CHAP-V2, as well as EAP protocols such as MD5-Challenge. EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication infrastructures such as RADIUS. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other cryptographic attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake. In EAP-TTLS, client and server communicate using attribute-value pairs encrypted within TLS. This generality allows arbitrary functions beyond authentication and key exchange to be added to the EAP negotiation, in a manner compatible with the AAA infrastructure. 2. Motivation Most password-based protocols in use today rely on a hash of the password with a random challenge. Thus, the server issues a challenge, the client hashes that challenge with the password and forwards a response to the server, and the server validates that response against the user's password retrieved from its database. This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5- Challenge and EAP/One-Time Password. An issue with such an approach is that an eavesdropper that observes both challenge and response may be able to mount a dictionary attack, in which random passwords are tested against the known Paul Funk expires January 2005 [Page 4] Internet-Draft April 2004 challenge to attempt to find one which results in the known response. Because passwords typically have low entropy, such attacks can in practice easily discover many passwords. While this vulnerability has long been understood, it has not been of great concern in environments where eavesdropping attacks are unlikely in practice. For example, users with wired or dial-up connections to their service providers have not been concerned that such connections may be monitored. Users have also been willing to entrust their passwords to their service providers, or at least to allow their service providers to view challenges and hashed responses which are then forwarded to their home authentication servers using, for example, proxy RADIUS, without fear that the service provider will mount dictionary attacks on the observed credentials. Because a user typically has a relationship with a single service provider, such trust is entirely manageable. With the advent of wireless connectivity, however, the situation changes dramatically: - Wireless connections are considerably more susceptible to eavesdropping and man-in-the-middle attacks. These attacks may enable dictionary attacks against low-entropy passwords. In addition, they may enable channel hijacking, in which an attacker gains fraudulent access by seizing control of the communications channel after authentication is complete. - Existing authentication protocols often begin by exchanging the clientĘs username in the clear. In the context of eavesdropping on the wireless channel, this can compromise the clientĘs anonymity and locational privacy. - Often in wireless networks, the access point does not reside in the administrative domain of the service provider with which the user has a relationship. For example, the access point may reside in an airport, coffee shop, or hotel in order to provide public access via 802.11. Even if password authentications are protected in the wireless leg, they may still be susceptible to eavesdropping within the untrusted wired network of the access point. - In the traditional wired world, the user typically intentionally connects with a particular service provider by dialing an associated phone number; that service provider may be required to route an authentication to the user's home domain. In a wireless network, however, the user does not get to choose an access domain, and must connect with whichever access point is nearby; providing for the routing of the authentication from an arbitrary access point to the user's home domain may pose a challenge. Paul Funk expires January 2005 [Page 5] Internet-Draft April 2004 Thus, the authentication requirements for a wireless environment that EAP-TTLS attempts to address can be summarized as follows: - Legacy password protocols must be supported, to allow easy deployment against existing authentication databases. - Password-based information must not be observable in the communications channel between the client node and a trusted service provider, to protect the user against dictionary attacks. - The user's identity must not be observable in the communications channel between the client node and a trusted service provider, to protect the user's locational privacy against surveillance, undesired acquisition of marketing information, and the like. - The authentication process must result in the distribution of shared keying information to the client and access point to permit encryption and validation of the wireless data connection subsequent to authentication, to secure it against eavesdroppers and prevent channel hijacking. - The authentication mechanism must support roaming among small access domains with which the user has no relationship and which will have limited capabilities for routing authentication requests. 3. Terminology AAA Authentication, Authorization and Accounting - functions that are generally required to control access to a network and support billing and auditing. AAA protocol A network protocol used to communicate with AAA servers; examples include RADIUS and Diameter. AAA server A server which performs one or more AAA functions: authenticating a user prior to granting network service, providing authorization (policy) information governing the type of network service the user is to be granted, and accumulating accounting information about actual usage. AAA/H A AAA server in the user's home domain, where authentication and authorization for that user are administered. Paul Funk expires January 2005 [Page 6] Internet-Draft April 2004 access point A network device providing users with a point of entry into the network, and which may enforce access control and policy based on information returned by a AAA server. For the purposes of this document, "access point" and "NAS" are architecturally equivalent. "Access point" is used throughout because it is suggestive of devices used for wireless access; "NAS" is used when more traditional forms of access, such as dial-up, are discussed. access domain The domain, including access points and other devices, that provides users with an initial point of entry into the network; for example, a wireless hot spot. client A host or device that connects to a network through an access point. domain A network and associated devices that are under the administrative control of an entity such as a service provider or the user's home organization. link layer protocol A protocol used to carry data between hosts that are connected within a single network segment; examples include PPP and Ethernet. NAI A Network Access Identifier [7], normally consisting of the name of the user and, optionally, the user's home realm. NAS A network device providing users with a point of entry into the network, and which may enforce access control and policy based on information returned by a AAA server. For the purposes of this document, "access point" and "NAS" are architecturally equivalent. "Access point" is used throughout because it is suggestive of devices used for wireless access; "NAS" is used when more traditional forms of access, such as dial-up, are discussed. proxy Paul Funk expires January 2005 [Page 7] Internet-Draft April 2004 A server that is able to route AAA transactions to the appropriate AAA server, possibly in another domain, typically based on the realm portion of an NAI. realm The optional part of an NAI indicating the domain to which a AAA transaction is to be routed, normally the user's home domain. service provider An organization with which a user has a business relationship, that provides network or other services. The service provider may provide the access equipment with which the user connects, may perform authentication or other AAA functions, may proxy AAA transactions to the user's home domain, etc. TTLS server A AAA server which implements EAP-TTLS. This server may also be capable of performing user authentication, or it may proxy the user authentication to a AAA/H. user The person operating the client device. Though the line is often blurred, "user" is intended to refer to the human being who is possessed of an identity (username), password or other authenticating information, and "client" is intended to refer to the device which makes use of this information to negotiate network access. There may also be clients with no human operators; in this case the term "user" is a convenient abstraction. 4. Architectural Model The network architectural model for EAP-TTLS usage and the type of security it provides is shown below. +----------+ +----------+ +----------+ +----------+ | | | | | | | | | client |<---->| access |<---->| TTLS AAA |<---->| AAA/H | | | | point | | server | | server | | | | | | | | | +----------+ +----------+ +----------+ +----------+ <---- secure password authentication tunnel ---> <---- secure data tunnel ----> Paul Funk expires January 2005 [Page 8] Internet-Draft April 2004 The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the TTLS server and AAA/H server might be a single entity; the access point and TTLS server might be a single entity; or, indeed, the functions of the access point, TTLS server and AAA/H server might be combined into a single physical device. The above diagram illustrates the division of labor among entities in a general manner and shows how a distributed system might be constructed; however, actual systems might be realized more simply. Note also that one or more AAA proxy servers might be deployed between access point and TTLS server, or between TTLS server and AAA/H server. Such proxies typically perform aggregation or are required for realm-based message routing. However, such servers play no direct role in EAP-TTLS and are therefore not shown. 4.1 Carrier Protocols The entities shown above communicate with each other using carrier protocols capable of encapsulating EAP. The client and access point communicate using a link layer carrier protocol such as PPP or EAPOL. The access point, TTLS server and AAA/H server communicate using a AAA carrier protocol such as RADIUS or Diameter. EAP, and therefore EAP-TTLS, must be initiated via the link layer protocol. In PPP or EAPOL, for example, EAP is initiated when the access point sends an EAP-Request/Identity packet to the client. The keying material used to encrypt and authenticate the data connection between the client and access point is developed implicitly between the client and TTLS server as a result of EAP- TTLS negotiation. This keying material must be communicated to the access point by the TTLS server using the AAA carrier protocol. The client and access point must also agree on an encryption/validation algorithm to be used based on the keying material. In some systems, both these devices may be preconfigured with this information, and distribution of the keying material alone is sufficient. Or, the link layer protocol may provide a mechanism for client and access point to negotiate an algorithm. In the most general case, however, it may be necessary for both client and access point to communicate their algorithm preferences to the TTLS server, and for the TTLS server to select one and communicate its choice to both parties. This information would be transported between access point and TTLS server via the AAA protocol, and between client and TTLS server via EAP-TTLS in encrypted form. Paul Funk expires January 2005 [Page 9] Internet-Draft April 2004 4.2 Security Relationships The client and access point have no pre-existing security relationship. The access point, TTLS server and AAA/H server are each assumed to have a pre-existing security association with the adjacent entity with which it communicates. With RADIUS, for example, this is achieved using shared secrets. It is essential for such security relationships to permit secure key distribution. The client and AAA/H server have a security relationship based on the user's credentials such as a password. The client and TTLS server may have a one-way security relationship based on the TTLS server's possession of a private key guaranteed by a CA certificate which the user trusts, or may have a mutual security relationship based on certificates for both parties. 4.3 Messaging The client and access point initiate an EAP conversation to negotiate the client's access to the network. Typically, the access point issues an EAP-Request/Identity to the client, which responds with an EAP-Response/Identity. Note that the client does not include the user's actual identity in this EAP-Response/Identity packet; the user's identity will not be transmitted until an encrypted channel has been established. The access point now acts as a passthrough device, allowing the TTLS server to negotiate EAP-TTLS with the client directly. During the first phase of the negotiation, the TLS handshake protocol is used to authenticate the TTLS server to the client and, optionally, to authenticate the client to the TTLS server, based on public/private key certificates. As a result of the handshake, client and TTLS server now have shared keying material and an agreed upon TLS record layer cipher suite with which to secure subsequent EAP-TTLS communication. During the second phase of negotiation, client and TTLS server use the secure TLS record layer channel established by the TLS handshake as a tunnel to exchange information encapsulated in attribute-value pairs, to perform additional functions such as client authentication and key distribution for the subsequent data connection. If a tunneled client authentication is performed, the TTLS server de-tunnels and forwards the authentication information to the AAA/H. If the AAA/H performs a challenge, the TTLS server tunnels the challenge information to the client. The AAA/H server may be a legacy device and needs to know nothing about EAP-TTLS; it only Paul Funk expires January 2005 [Page 10] Internet-Draft April 2004 needs to be able to authenticate the client based on commonly used authentication protocols. Keying material for the subsequent data connection between client and access point may be generated based on secret information developed during the TLS handshake between client and TTLS server. At the conclusion of a successful authentication, the TTLS server may transmit this keying material to the access point, encrypted based on the existing security associations between those devices (e.g., RADIUS). The client and access point now share keying material which they can use to encrypt data traffic between them. 4.4 Resulting Security As the diagram above indicates, EAP-TTLS allows user identity and password information to be securely transmitted between client and TTLS server, and performs key distribution to allow network data subsequent to authentication to be securely transmitted between client and access point. 5. Protocol Layering Model EAP-TTLS packets are encapsulated within EAP, and EAP in turn requires a carrier protocol to transport it. EAP-TTLS packets themselves encapsulate TLS, which is then used to encapsulate user authentication information. Thus, EAP-TTLS messaging can be described using a layered model, where each layer is encapsulated by the layer beneath it. The following diagram clarifies the relationship between protocols: +--------------------------------------------------------+ | User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.)| +--------------------------------------------------------+ | TLS | +--------------------------------------------------------+ | EAP-TTLS | +--------------------------------------------------------+ | EAP | +--------------------------------------------------------+ | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | +--------------------------------------------------------+ When the user authentication protocol is itself EAP, the layering is as follows: Paul Funk expires January 2005 [Page 11] Internet-Draft April 2004 +--------------------------------------------------------+ | User EAP Authentication Protocol (MD-Challenge, etc.) | +--------------------------------------------------------+ | EAP | +--------------------------------------------------------+ | TLS | +--------------------------------------------------------+ | EAP-TTLS | +--------------------------------------------------------+ | EAP | +--------------------------------------------------------+ | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | +--------------------------------------------------------+ Methods for encapsulating EAP within carrier protocols are already defined. For example, PPP [5] or EAPOL [4] may be used to transport EAP between client and access point; RADIUS [6] or Diameter [8] are used to transport EAP between access point and TTLS server. 6. EAP-TTLS version 0 Overview [Authors' note: This section as well as sections 7, 8, 9 and 10, describe version 0 of the EAP-TTLS protocol. Section 11 describes version 1 of EAP-TTLS. Much of the material describing version 0 also applies to version 1; the version 1 documentation will refer to the version 0 material as required. The intention is to provide a separate draft for each of the two versions in the near future.] A EAP-TTLS negotiation comprises two phases: the TLS handshake phase and the TLS tunnel phase. During phase 1, TLS is used to authenticate the TTLS server to the client and, optionally, the client to the TTLS server. Phase 1 results in the activation of a cipher suite, allowing phase 2 to proceed securely using the TLS record layer. (Note that the type and degree of security in phase 2 depends on the cipher suite negotiated during phase 1; if the null cipher suite is negotiated, there will be no security!) During phase 2, the TLS record layer is used to tunnel information between client and TTLS server to perform any of a number of functions. These might include user authentication, negotiation of data communication security capabilities, key distribution, communication of accounting information, etc.. Information between client and TTLS server is exchanged via attribute-value pairs (AVPs) compatible with RADIUS and Diameter; thus, any type of function that can be implemented via such AVPs may easily be performed. EAP-TTLS specifies how user authentication may be performed during phase 2. The user authentication may itself be EAP, or it may be a legacy protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Phase 2 Paul Funk expires January 2005 [Page 12] Internet-Draft April 2004 user authentication may not always be necessary, since the user may already have been authenticated via the mutual authentication option of the TLS handshake protocol. EAP-TTLS is also intended for use in key distribution, and specifies how keying materi