PPPEXT Working Group Paul Funk
Internet-Draft Funk Software, Inc.
Category: Standards Track Simon Blake-Wilson
<draft-ietf-pppext-eap-ttls-05.txt> 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