GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5281

Network Working Group P. Funk Request for Comments: 5281 Unaffiliated Category: Informational S. Blake-Wilson

                                                               SafeNet
                                                           August 2008
Extensible Authentication Protocol Tunneled Transport Layer Security
           Authenticated Protocol Version 0 (EAP-TTLSv0)

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 EAP-TTLS is an EAP (Extensible Authentication Protocol) method that
 encapsulates a TLS (Transport Layer Security) session, consisting of
 a handshake phase and a data phase.  During the handshake phase, the
 server is authenticated to the client (or client and server are
 mutually authenticated) using standard TLS procedures, and keying
 material is generated in order to create a cryptographically secure
 tunnel for information exchange in the subsequent data phase.  During
 the data phase, the client is authenticated to the server (or client
 and server are mutually authenticated) using an arbitrary
 authentication mechanism encapsulated within the secure tunnel.  The
 encapsulated authentication mechanism 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 attacks.  The data phase
 may also be used for additional, arbitrary data exchange.

Funk & Blake-Wilson Informational [Page 1] RFC 5281 EAP-TTLSv0 August 2008

Table of Contents

 1. Introduction ....................................................4
 2. Motivation ......................................................5
 3. Requirements Language ...........................................7
 4. Terminology .....................................................7
 5. Architectural Model .............................................9
    5.1. Carrier Protocols .........................................10
    5.2. Security Relationships ....................................10
    5.3. Messaging .................................................11
    5.4. Resulting Security ........................................12
 6. Protocol Layering Model ........................................12
 7. EAP-TTLS Overview ..............................................13
    7.1. Phase 1: Handshake ........................................14
    7.2. Phase 2: Tunnel ...........................................14
    7.3. EAP Identity Information ..................................15
    7.4. Piggybacking ..............................................15
    7.5. Session Resumption ........................................16
    7.6. Determining Whether to Enter Phase 2 ......................17
    7.7. TLS Version ...............................................18
    7.8. Use of TLS PRF ............................................18
 8. Generating Keying Material .....................................19
 9. EAP-TTLS Protocol ..............................................20
    9.1. Packet Format .............................................20
    9.2. EAP-TTLS Start Packet .....................................21
         9.2.1. Version Negotiation ................................21
         9.2.2. Fragmentation ......................................22
         9.2.3. Acknowledgement Packets ............................22
 10. Encapsulation of AVPs within the TLS Record Layer .............23
    10.1. AVP Format ...............................................23
    10.2. AVP Sequences ............................................25
    10.3. Guidelines for Maximum Compatibility with AAA Servers ....25
 11. Tunneled Authentication .......................................26
    11.1. Implicit Challenge .......................................26
    11.2. Tunneled Authentication Protocols ........................27
         11.2.1. EAP ...............................................27
         11.2.2. CHAP ..............................................29
         11.2.3. MS-CHAP ...........................................30
         11.2.4. MS-CHAP-V2 ........................................30
         11.2.5. PAP ...............................................32
    11.3. Performing Multiple Authentications ......................33
    11.4. Mandatory Tunneled Authentication Support ................34
    11.5. Additional Suggested Tunneled Authentication Support .....34
 12. Keying Framework ..............................................35
    12.1. Session-Id ...............................................35
    12.2. Peer-Id ..................................................35
    12.3. Server-Id ................................................35
 13. AVP Summary ...................................................35

Funk & Blake-Wilson Informational [Page 2] RFC 5281 EAP-TTLSv0 August 2008

 14. Security Considerations .......................................36
    14.1. Security Claims ..........................................36
         14.1.1. Authentication Mechanism ..........................36
         14.1.2. Ciphersuite Negotiation ...........................37
         14.1.3. Mutual Authentication .............................37
         14.1.4. Integrity Protection ..............................37
         14.1.5. Replay Protection .................................37
         14.1.6. Confidentiality ...................................37
         14.1.7. Key Derivation ....................................37
         14.1.8. Key Strength ......................................37
         14.1.9. Dictionary Attack Protection ......................38
         14.1.10. Fast Reconnect ...................................38
         14.1.11. Cryptographic Binding ............................38
         14.1.12. Session Independence .............................38
         14.1.13. Fragmentation ....................................38
         14.1.14. Channel Binding ..................................38
    14.2. Client Anonymity .........................................38
    14.3. Server Trust .............................................39
    14.4. Certificate Validation ...................................39
    14.5. Certificate Compromise ...................................40
    14.6. Forward Secrecy ..........................................40
    14.7. Negotiating-Down Attacks .................................40
 15. Message Sequences .............................................41
    15.1. Successful Authentication via Tunneled CHAP ..............41
    15.2. Successful Authentication via Tunneled
          EAP/MD5-Challenge ........................................43
    15.3. Successful Session Resumption ............................46
 16. IANA Considerations ...........................................47
 17. Acknowledgements ..............................................48
 18. References ....................................................48
    18.1. Normative References .....................................48
    18.2. Informative References ...................................49

Funk & Blake-Wilson Informational [Page 3] RFC 5281 EAP-TTLSv0 August 2008

1. Introduction

 Extensible Authentication Protocol (EAP) [RFC3748] defines a standard
 message exchange that allows a server to authenticate a client using
 an authentication method agreed upon by both parties.  EAP may be
 extended with additional authentication methods by registering such
 methods with IANA or by defining vendor-specific methods.
 Transport Layer Security (TLS) [RFC4346] 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 defined as an authentication protocol for use within EAP
 (EAP-TLS) [RFC5216].
 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 [RFC2865], Diameter
 [RFC3588], or other AAA servers.  These include non-EAP protocols
 such as PAP [RFC1661], CHAP [RFC1661], MS-CHAP [RFC2433], or MS-
 CHAP-V2 [RFC2759], as well as EAP protocols such as MD5-Challenge
 [RFC3748].
 EAP-TTLS is an EAP method that provides functionality beyond what is
 available in EAP-TLS.  EAP-TTLS has been widely deployed and this
 specification documents what existing implementations do.  It has
 some limitations and vulnerabilities, however.  These are addressed
 in EAP-TTLS extensions and ongoing work in the creation of
 standardized tunneled EAP methods at the IETF.  Users of EAP-TTLS are
 strongly encouraged to consider these in their deployments.
 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 authentication 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.  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 attacks.

Funk & Blake-Wilson Informational [Page 4] RFC 5281 EAP-TTLSv0 August 2008

 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.
 The main limitation of EAP-TTLS is that its base version lacks
 support for cryptographic binding between the outer and inner
 authentication.  Please refer to Section 14.1.11 for details and the
 conditions where this vulnerability exists.  It should be noted that
 an extension for EAP-TTLS [TTLS-EXT] fixed this vulnerability.  Users
 of EAP-TTLS are strongly encouraged to adopt this extension.

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 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.

Funk & Blake-Wilson Informational [Page 5] RFC 5281 EAP-TTLSv0 August 2008

 With the advent of wireless connectivity, however, the situation
 changes dramatically:
  1. 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.
  1. 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.
  1. 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 [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.
  1. 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.
 Thus, the authentication requirements for a wireless environment that
 EAP-TTLS attempts to address can be summarized as follows:
  1. Legacy password protocols must be supported, to allow easy

deployment against existing authentication databases.

  1. 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.
  1. 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 against surveillance, undesired acquisition of
    marketing information, and the like.

Funk & Blake-Wilson Informational [Page 6] RFC 5281 EAP-TTLSv0 August 2008

  1. 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.
  1. The authentication mechanism must support roaming among access

domains with which the user has no relationship and which will

    have limited capabilities for routing authentication requests.

3. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

4. 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.
 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.  Since the access point
    terminates the server side of the EAP conversation, for the

Funk & Blake-Wilson Informational [Page 7] RFC 5281 EAP-TTLSv0 August 2008

    purposes of this document it is therefore equivalent to the
    "authenticator", as used in the EAP specification [RFC3748].
    Since the access point acts as a client to a AAA server, for the
    purposes of this document it is therefore also equivalent to the
    "Network Access Server (NAS)", as used in AAA specifications such
    as [RFC2865].
 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.  Since it terminates the client side of the EAP
    conversation, for the purposes of this document, it is therefore
    equivalent to the "peer", as used in the EAP specification
    [RFC3748].
 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
    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 [RFC4282], normally consisting of the
    name of the user and, optionally, the user's home realm.
 proxy
    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.

Funk & Blake-Wilson Informational [Page 8] RFC 5281 EAP-TTLSv0 August 2008

 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.

5. 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 ---->
 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

Funk & Blake-Wilson Informational [Page 9] RFC 5281 EAP-TTLSv0 August 2008

 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.

5.1. Carrier Protocols

 The entities shown above communicate with each other using carrier
 protocols capable of encapsulating EAP.  The client and access point
 communicate typically using a link layer carrier protocol such as PPP
 or EAPOL (EAP over LAN).  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 carrier
 protocol between client and access point.  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 the
 EAP-TTLS negotiation.  This keying material must be communicated to
 the access point by the TTLS server using the AAA carrier protocol.

5.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.

Funk & Blake-Wilson Informational [Page 10] RFC 5281 EAP-TTLSv0 August 2008

5.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 need not include the
 user's actual identity in this EAP-Response/Identity packet other
 than for routing purposes (e.g., realm information; see Section 7.3
 and [RFC3748], Section 5.1); the user's actual identity need 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 authentication (one-
 way or mutual), validation of client integrity and configuration,
 provisioning of information required for data connectivity, etc.
 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 issues 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 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 (Master Session Key / Extended Master Session Key
 (MSK/EMSK); see Section 8) is 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 that they can
 use to encrypt data traffic between them.

Funk & Blake-Wilson Informational [Page 11] RFC 5281 EAP-TTLSv0 August 2008

5.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 generates keying material to allow network data
 subsequent to authentication to be securely transmitted between
 client and access point.

6. 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
 attribute-value pairs (AVPs) which may carry user authentication or
 other 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:
 +-----------------------------------------------------------+
 | AVPs, including authentication (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:
 +-----------------------------------------------------------+
 |              EAP Method (MD-Challenge, etc.)              |
 +-----------------------------------------------------------+
 |                    AVPs, including EAP                    |
 +-----------------------------------------------------------+
 |                            TLS                            |
 +-----------------------------------------------------------+
 |                         EAP-TTLS                          |
 +-----------------------------------------------------------+
 |                            EAP                            |
 +-----------------------------------------------------------+
 |   Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.)   |
 +-----------------------------------------------------------+

Funk & Blake-Wilson Informational [Page 12] RFC 5281 EAP-TTLSv0 August 2008

 Methods for encapsulating EAP within carrier protocols are already
 defined.  For example, PPP [RFC1661] or EAPOL [802.1X] may be used to
 transport EAP between client and access point; RADIUS [RFC2865] or
 Diameter [RFC3588] are used to transport EAP between access point and
 TTLS server.

7. EAP-TTLS Overview

 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, client integrity
 validation, 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
 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.
 Functions other than authentication MAY also be performed during
 phase 2.  This document does not define any such functions; however,
 any organization or standards body is free to specify how additional
 functions may be performed through the use of appropriate AVPs.
 EAP-TTLS specifies how keying material for the data connection
 between client and access point is generated.  The keying material is
 developed implicitly between client and TTLS server based on the
 results of the TLS handshake; the TTLS server will communicate the
 keying material to the access point over the carrier protocol.

Funk & Blake-Wilson Informational [Page 13] RFC 5281 EAP-TTLSv0 August 2008

7.1. Phase 1: Handshake

 In phase 1, the TLS handshake protocol is used to authenticate the
 TTLS server to the client and, optionally, to authenticate the client
 to the TTLS server.
 The TTLS server initiates the EAP-TTLS method with an EAP-TTLS/Start
 packet, which is an EAP-Request with Type = EAP-TTLS and the S
 (Start) bit set.  This indicates to the client that it should begin
 the TLS handshake by sending a ClientHello message.
 EAP packets continue to be exchanged between client and TTLS server
 to complete the TLS handshake, as described in [RFC5216].  Phase 1 is
 completed when the client and TTLS server exchange ChangeCipherSpec
 and Finished messages.  At this point, additional information may be
 securely tunneled.
 As part of the TLS handshake protocol, the TTLS server will send its
 certificate along with a chain of certificates leading to the
 certificate of a trusted CA.  The client will need to be configured
 with the certificate of the trusted CA in order to perform the
 authentication.
 If certificate-based authentication of the client is desired, the
 client must have been issued a certificate and must have the private
 key associated with that certificate.

7.2. Phase 2: Tunnel

 In phase 2, the TLS record layer is used to securely tunnel
 information between client and TTLS server.  This information is
 encapsulated in sequences of attribute-value pairs (AVPs), whose use
 and format are described in later sections.
 Any type of information may be exchanged during phase 2, according to
 the requirements of the system.  (It is expected that applications
 utilizing EAP-TTLS will specify what information must be exchanged
 and therefore which AVPs must be supported.)  The client begins the
 phase 2 exchange by encoding information in a sequence of AVPs,
 passing this sequence to the TLS record layer for encryption, and
 sending the resulting data to the TTLS server.
 The TTLS server recovers the AVPs in clear text from the TLS record
 layer.  If the AVP sequence includes authentication information, it
 forwards this information to the AAA/H server using the AAA carrier
 protocol.  Note that the EAP-TTLS and AAA/H servers may be one and
 the same; in which case, it simply processes the information locally.

Funk & Blake-Wilson Informational [Page 14] RFC 5281 EAP-TTLSv0 August 2008

 The TTLS server may respond with its own sequence of AVPs.  The TTLS
 server passes the AVP sequence to the TLS record layer for encryption
 and sends the resulting data to the client.  For example, the TTLS
 server may forward an authentication challenge received from the
 AAA/H.
 This process continues until the AAA/H either accepts or rejects the
 client, resulting in the TTLS server completing the EAP-TTLS
 negotiation and indicating success or failure to the encapsulating
 EAP protocol (which normally results in a final EAP-Success or EAP-
 Failure being sent to the client).
 The TTLS server distributes data connection keying information and
 other authorization information to the access point in the same AAA
 carrier protocol message that carries the final EAP-Success or other
 success indication.

7.3. EAP Identity Information

 The identity of the user is provided during phase 2, where it is
 protected by the TLS tunnel.  However, prior to beginning the EAP-
 TTLS authentication, the client will typically issue an EAP-
 Response/Identity packet as part of the EAP protocol, containing a
 username in clear text.  To preserve user anonymity against
 eavesdropping, this packet specifically SHOULD NOT include the actual
 name of the user; instead, it SHOULD use a blank or placeholder such
 as "anonymous".  However, this privacy constraint is not intended to
 apply to any information within the EAP-Response/Identity that is
 required for routing; thus, the EAP-Response/Identity packet MAY
 include the name of the realm of a trusted provider to which EAP-TTLS
 packets should be forwarded; for example, "anonymous@myisp.com".
 Note that at the time the initial EAP-Response/Identity packet is
 sent the EAP method is yet to be negotiated.  If, in addition to EAP-
 TTLS, the client is willing to negotiate use of EAP methods that do
 not support user anonymity, then the client MAY include the name of
 the user in the EAP-Response/Identity to meet the requirements of the
 other candidate EAP methods.

7.4. Piggybacking

 While it is convenient to describe EAP-TTLS messaging in terms of two
 phases, it is sometimes required that a single EAP-TTLS packet
 contain both phase 1 and phase 2 TLS messages.
 Such "piggybacking" occurs when the party that completes the
 handshake also has AVPs to send.  For example, when negotiating a
 resumed TLS session, the TTLS server sends its ChangeCipherSpec and

Funk & Blake-Wilson Informational [Page 15] RFC 5281 EAP-TTLSv0 August 2008

 Finished messages first, then the client sends its own
 ChangeCipherSpec and Finished messages to conclude the handshake.  If
 the client has authentication or other AVPs to send to the TTLS
 server, it MUST tunnel those AVPs within the same EAP-TTLS packet
 immediately following its Finished message.  If the client fails to
 do this, the TTLS server will incorrectly assume that the client has
 no AVPs to send, and the outcome of the negotiation could be
 affected.

7.5. Session Resumption

 When a client and TTLS server that have previously negotiated an
 EAP-TTLS session begin a new EAP-TTLS negotiation, the client and
 TTLS server MAY agree to resume the previous session.  This
 significantly reduces the time required to establish the new session.
 This could occur when the client connects to a new access point, or
 when an access point requires reauthentication of a connected client.
 Session resumption is accomplished using the standard TLS mechanism.
 The client signals its desire to resume a session by including the
 session ID of the session it wishes to resume in the ClientHello
 message; the TTLS server signals its willingness to resume that
 session by echoing that session ID in its ServerHello message.
 If the TTLS server elects not to resume the session, it simply does
 not echo the session ID, causing a new session to be negotiated.
 This could occur if the TTLS server is configured not to resume
 sessions, if it has not retained the requested session's state, or if
 the session is considered stale.  A TTLS server may consider the
 session stale based on its own configuration, or based on session-
 limiting information received from the AAA/H (e.g., the RADIUS
 Session-Timeout attribute).
 Tunneled authentication is specifically not performed for resumed
 sessions; the presumption is that the knowledge of the master secret
 (as evidenced by the ability to resume the session) is authentication
 enough.  This allows session resumption to occur without any
 messaging between the TTLS server and the AAA/H.  If periodic
 reauthentication to the AAA/H is desired, the AAA/H must indicate
 this to the TTLS server when the original session is established, for
 example, using the RADIUS Session-Timeout attribute.
 The client MAY send other AVPs in its first phase 2 message of a
 session resumption, to initiate non-authentication functions.  If it
 does not, the TTLS server, at its option, MAY send AVPs to the client
 to initiate non-authentication functions, or MAY simply complete the
 EAP-TTLS negotiation and indicate success or failure to the
 encapsulating EAP protocol.

Funk & Blake-Wilson Informational [Page 16] RFC 5281 EAP-TTLSv0 August 2008

 The TTLS server MUST retain authorization information returned by the
 AAA/H for use in resumed sessions.  A resumed session MUST operate
 under the same authorizations as the original session, and the TTLS
 server must be prepared to send the appropriate information back to
 the access point.  Authorization information might include the
 maximum time for the session, the maximum allowed bandwidth, packet
 filter information, and the like.  The TTLS server is responsible for
 modifying time values, such as Session-Timeout, appropriately for
 each resumed session.
 A TTLS server MUST NOT permit a session to be resumed if that session
 did not result in a successful authentication of the user during
 phase 2.  The consequence of incorrectly implementing this aspect of
 session resumption would be catastrophic; any attacker could easily
 gain network access by first initiating a session that succeeds in
 the TLS handshake but fails during phase 2 authentication, and then
 resuming that session.
 [Implementation note: Toolkits that implement TLS often cache
 resumable TLS sessions automatically.  Implementers must take care to
 override such automatic behavior, and prevent sessions from being
 cached for possible resumption until the user has been positively
 authenticated during phase 2.]

7.6. Determining Whether to Enter Phase 2

 Entering phase 2 is optional, and may be initiated by either client
 or TTLS server.  If no further authentication or other information
 exchange is required upon completion of phase 1, it is possible to
 successfully complete the EAP-TTLS negotiation without ever entering
 phase 2 or tunneling any AVPs.
 Scenarios in which phase 2 is never entered include:
  1. Successful session resumption, with no additional information

exchange required,

  1. Authentication of the client via client certificate during phase

1, with no additional authentication or information exchange

    required.
 The client always has the first opportunity to initiate phase 2 upon
 completion of phase 1.  If the client has no AVPs to send, it either
 sends an Acknowledgement (see Section 9.2.3) if the TTLS server sends
 the final phase 1 message, or simply does not piggyback a phase 2
 message when it issues the final phase 1 message (as will occur
 during session resumption).

Funk & Blake-Wilson Informational [Page 17] RFC 5281 EAP-TTLSv0 August 2008

 If the client does not initiate phase 2, the TTLS server, at its
 option, may either complete the EAP-TTLS negotiation without entering
 phase 2 or initiate phase 2 by tunneling AVPs to the client.
 For example, suppose a successful session resumption occurs in phase
 1.  The following sequences are possible:
  1. Neither the client nor TTLS server has additional information to

exchange. The client completes phase 1 without piggybacking phase

    2 AVPs, and the TTLS server indicates success to the encapsulating
    EAP protocol without entering phase 2.
  1. The client has no additional information to exchange, but the TTLS

server does. The client completes phase 1 without piggybacking

    phase 2 AVPs, but the TTLS server extends the EAP-TTLS negotiation
    into phase 2 by tunneling AVPs in its next EAP-TTLS message.
  1. The client has additional information to exchange, and piggybacks

phase 2 AVPs with its final phase 1 message, thus extending the

    negotiation into phase 2.

7.7. TLS Version

 TLS version 1.0 [RFC2246], 1.1 [RFC4346], or any subsequent version
 MAY be used within EAP-TTLS.  TLS provides for its own version
 negotiation mechanism.
 For maximum interoperability, EAP-TTLS implementations SHOULD support
 TLS version 1.0.

7.8. Use of TLS PRF

 EAP-TTLSv0 utilizes a pseudo-random function (PRF) to generate keying
 material (Section 8) and to generate implicit challenge material for
 certain authentication methods (Section 11.1).  The PRF used in these
 computations is the TLS PRF used in the TLS handshake negotiation
 that initiates the EAP-TTLS exchange.
 TLS versions 1.0 [RFC2246] and 1.1 [RFC4346] define the same PRF
 function, and any EAP-TTLSv0 implementation based on these versions
 of TLS must use the PRF defined therein.  It is expected that future
 versions of or extensions to the TLS protocol will permit alternative
 PRF functions to be negotiated.  If an alternative PRF function is
 specified for the underlying TLS version or has been negotiated
 during the TLS handshake negotiation, then that alternative PRF
 function must be used in EAP-TTLSv0 computations instead of the TLS
 1.0/1.1 PRF.

Funk & Blake-Wilson Informational [Page 18] RFC 5281 EAP-TTLSv0 August 2008

 The TLS PRF function used in this specification is denoted as
 follows:
       PRF-nn(secret, label, seed)
 where:
       nn is the number of generated octets
       secret is a secret key
       label is a string (without null-terminator)
       seed is a binary sequence.
 The TLS 1.0/1.1 PRF has invariant output regardless of how many
 octets are generated.  However, it is possible that alternative PRF
 functions will include the size of the output sequence as input to
 the PRF function; this means generating 32 octets and generating 64
 octets from the same input parameters will no longer result in the
 first 32 octets being identical.  For this reason, the PRF is always
 specified with an "nn", indicating the number of generated octets.

8. Generating Keying Material

 Upon successful conclusion of an EAP-TTLS negotiation, 128 octets of
 keying material are generated and exported for use in securing the
 data connection between client and access point.  The first 64 octets
 of the keying material constitute the MSK, the second 64 octets
 constitute the EMSK.
 The keying material is generated using the TLS PRF function
 [RFC4346], with inputs consisting of the TLS master secret, the
 ASCII-encoded constant string "ttls keying material", the TLS client
 random, and the TLS server random.  The constant string is not null-
 terminated.
    Keying Material = PRF-128(SecurityParameters.master_secret, "ttls
              keying material", SecurityParameters.client_random +
              SecurityParameters.server_random)
    MSK = Keying Material [0..63]
    EMSK = Keying Material [64..127]

Funk & Blake-Wilson Informational [Page 19] RFC 5281 EAP-TTLSv0 August 2008

 Note that the order of client_random and server_random for EAP-TTLS
 is reversed from that of the TLS protocol [RFC4346].  This ordering
 follows the key derivation method of EAP-TLS [RFC5216].  Altering the
 order of randoms avoids namespace collisions between constant strings
 defined for EAP-TTLS and those defined for the TLS protocol.
 The TTLS server distributes this keying material to the access point
 via the AAA carrier protocol.  When RADIUS is the AAA carrier
 protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes [RFC2548]
 may be used to distribute the first 32 octets and second 32 octets of
 the MSK, respectively.

9. EAP-TTLS Protocol

9.1. Packet Format

 The EAP-TTLS packet format is shown below.  The fields are
 transmitted left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |   Identifier  |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |     Flags     |        Message Length
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Message Length         |             Data...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Code
    1 for request, 2 for response.
 Identifier
    The Identifier field is one octet and aids in matching responses
    with requests.  The Identifier field MUST be changed for each
    request packet and MUST be echoed in each response packet.
 Length
    The Length field is two octets and indicates the number of octets
    in the entire EAP packet, from the Code field through the Data
    field.
 Type
    21 (EAP-TTLS)

Funk & Blake-Wilson Informational [Page 20] RFC 5281 EAP-TTLSv0 August 2008

 Flags
      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | L | M | S | R | R |     V     |
    +---+---+---+---+---+---+---+---+
    L = Length included
    M = More fragments
    S = Start
    R = Reserved
    V = Version (000 for EAP-TTLSv0)
    The L bit is set to indicate the presence of the four-octet TLS
    Message Length field.  The M bit indicates that more fragments are
    to come.  The S bit indicates a Start message.  The V field is set
    to the version of EAP-TTLS, and is set to 000 for EAP-TTLSv0.
 Message Length
    The Message Length field is four octets, and is present only if
    the L bit is set.  This field provides the total length of the raw
    data message sequence prior to fragmentation.
 Data
    For all packets other than a Start packet, the Data field consists
    of the raw TLS message sequence or fragment thereof.  For a Start
    packet, the Data field may optionally contain an AVP sequence.

9.2. EAP-TTLS Start Packet

 The S bit MUST be set on the first packet sent by the server to
 initiate the EAP-TTLS protocol.  It MUST NOT be set on any other
 packet.
 This packet MAY contain additional information in the form of AVPs,
 which may provide useful hints to the client; for example, the server
 identity may be useful to the client to allow it to pick the correct
 TLS session ID for session resumption.  Each AVP must begin on a
 four-octet boundary relative to the first AVP in the sequence.  If an
 AVP is not a multiple of four octets, it must be padded with zeros to
 the next four-octet boundary.

9.2.1. Version Negotiation

 The version of EAP-TTLS is negotiated in the first exchange between
 server and client.  The server sets the highest version number of
 EAP-TTLS that it supports in the V field of its Start message (in the
 case of EAP-TTLSv0, this is 0).  In its first EAP message in
 response, the client sets the V field to the highest version number

Funk & Blake-Wilson Informational [Page 21] RFC 5281 EAP-TTLSv0 August 2008

 that it supports that is no higher than the version number offered by
 the server.  If the client version is not acceptable to the server,
 it sends an EAP-Failure to terminate the EAP session.  Otherwise, the
 version sent by the client is the version of EAP-TTLS that MUST be
 used, and both server and client MUST set the V field to that version
 number in all subsequent EAP messages.

9.2.2. Fragmentation

 Each EAP-TTLS message contains a single leg of a half-duplex
 conversation.  The EAP carrier protocol (e.g., PPP, EAPOL, RADIUS)
 may impose constraints on the length of an EAP message.  Therefore it
 may be necessary to fragment an EAP-TTLS message across multiple EAP
 messages.
 Each fragment except for the last MUST have the M bit set, to
 indicate that more data is to follow; the final fragment MUST NOT
 have the M bit set.
 If there are multiple fragments, the first fragment MUST have the L
 bit set and include the length of the entire raw message prior to
 fragmentation.  Fragments other than the first MUST NOT have the L
 bit set.  Unfragmented messages MAY have the L bit set and include
 the length of the message (though this information is redundant).
 Upon receipt of a packet with the M bit set, the receiver MUST
 transmit an Acknowledgement packet.  The receiver is responsible for
 reassembly of fragmented packets.

9.2.3. Acknowledgement Packets

 An Acknowledgement packet is an EAP-TTLS packet with no additional
 data beyond the Flags octet, and with the L, M, and S bits of the
 Flags octet set to 0.  (Note, however, that the V field MUST still be
 set to the appropriate version number.)
 An Acknowledgement packet is sent for the following purposes:
  1. A Fragment Acknowledgement is sent in response to an EAP packet

with the M bit set.

  1. When the final EAP packet of the EAP-TTLS negotiation is sent by

the TTLS server, the client must respond with an Acknowledgement

    packet, to allow the TTLS server to proceed with the EAP protocol
    upon completion of EAP-TTLS (typically by sending or causing to be
    sent a final EAP-Success or EAP-Failure to the client).

Funk & Blake-Wilson Informational [Page 22] RFC 5281 EAP-TTLSv0 August 2008

10. Encapsulation of AVPs within the TLS Record Layer

 Subsequent to the TLS handshake, information may be tunneled between
 client and TTLS server through the use of attribute-value pairs
 (AVPs) encrypted within the TLS record layer.
 The AVP format chosen for EAP-TTLS is compatible with the Diameter
 AVP format.  This does not represent a requirement that Diameter be
 supported by any of the devices or servers participating in an EAP-
 TTLS negotiation.  Use of this format is merely a convenience.
 Diameter is a superset of RADIUS and includes the RADIUS attribute
 namespace by definition, though it does not limit the size of an AVP
 as does RADIUS; RADIUS, in turn, is a widely deployed AAA protocol
 and attribute definitions exist for all commonly used password
 authentication protocols, including EAP.
 Thus, Diameter is not considered normative except as specified in
 this document.  Specifically, the representation of the Data field of
 an AVP in EAP-TTLS is identical to that of Diameter.
 Use of the RADIUS/Diameter namespace allows a TTLS server to easily
 translate between AVPs it uses to communicate to clients and the
 protocol requirements of AAA servers that are widely deployed.  Plus,
 it provides a well-understood mechanism to allow vendors to extend
 that namespace for their particular requirements.
 It is expected that the AVP Codes used in EAP-TTLS will carry roughly
 the same meaning in EAP-TTLS as they do in Diameter and, by
 extension, RADIUS.  However, although EAP-TTLS uses the same AVP
 Codes and syntax as Diameter, the semantics may differ, and most
 Diameter AVPs do not have any well-defined semantics in EAP-TTLS.  A
 separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be
 used within EAP-TTLS and their semantics in this context (see Section
 16 for details).  A TTLS server copying AVPs between an EAP-TTLS
 exchange and a Diameter or RADIUS exchange with a backend MUST NOT
 make assumptions about AVPs whose usage in either EAP-TTLS or the
 backend protocol it does not understand.  Therefore, a TTLS server
 MUST NOT copy an AVP between an EAP-TTLS exchange and a Diameter or
 RADIUS exchange unless the semantics of the AVP are understood and
 defined in both contexts.

10.1. AVP Format

 The format of an AVP is shown below.  All items are in network, or
 big-endian, order; that is, they have the most significant octet
 first.

Funk & Blake-Wilson Informational [Page 23] RFC 5281 EAP-TTLSv0 August 2008

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           AVP Code                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |V M r r r r r r|                  AVP Length                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Vendor-ID (opt)                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Data ...
 +-+-+-+-+-+-+-+-+
 AVP Code
    The AVP Code is four octets and, combined with the Vendor-ID field
    if present, identifies the attribute uniquely.  The first 256 AVP
    numbers represent attributes defined in RADIUS [RFC2865].  AVP
    numbers 256 and above are defined in Diameter [RFC3588].
 AVP Flags
    The AVP Flags field is one octet and provides the receiver with
    information necessary to interpret the AVP.
    The 'V' (Vendor-Specific) bit indicates whether the optional
    Vendor-ID field is present.  When set to 1, the Vendor-ID field is
    present and the AVP Code is interpreted according to the namespace
    defined by the vendor indicated in the Vendor-ID field.
    The 'M' (Mandatory) bit indicates whether support of the AVP is
    required.  If this bit is set to 0, this indicates that the AVP
    may be safely ignored if the receiving party does not understand
    or support it.  If set to 1, this indicates that the receiving
    party MUST fail the negotiation if it does not understand the AVP;
    for a TTLS server, this would imply returning EAP-Failure, for a
    client, this would imply abandoning the negotiation.
    The 'r' (reserved) bits are unused and MUST be set to 0 by the
    sender and MUST be ignored by the receiver.
 AVP Length
    The AVP Length field is three octets and indicates the length of
    this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
    (if present), and Data.

Funk & Blake-Wilson Informational [Page 24] RFC 5281 EAP-TTLSv0 August 2008

 Vendor-ID
    The Vendor-ID field is present if the V bit is set in the AVP
    Flags field.  It is four octets and contains the vendor's IANA-
    assigned "SMI Network Management Private Enterprise Codes"
    [RFC3232] value.  Vendors defining their own AVPs must maintain a
    consistent namespace for use of those AVPs within RADIUS,
    Diameter, and EAP-TTLS.
    A Vendor-ID value of zero is equivalent to absence of the Vendor-
    ID field altogether.
 Note that the M bit provides a means for extending the functionality
 of EAP-TTLS while preserving backward compatibility when desired.  By
 setting the M bit of the appropriate AVP(s) to 0 or 1, the party
 initiating the function indicates that support of the function by the
 other party is either optional or required.

10.2. AVP Sequences

 Data encapsulated within the TLS record layer must consist entirely
 of a sequence of zero or more AVPs.  Each AVP must begin on a four-
 octet boundary relative to the first AVP in the sequence.  If an AVP
 is not a multiple of four octets, it must be padded with zeros to the
 next four-octet boundary.
 Note that the AVP Length does not include the padding.

10.3. Guidelines for Maximum Compatibility with AAA Servers

 For maximum compatibility with AAA servers, the following guidelines
 for AVP usage are suggested:
  1. Non-vendor-specific AVPs intended for use with AAA servers should

be selected from the set of attributes defined for RADIUS; that

    is, attributes with codes less than 256.  This provides
    compatibility with both RADIUS and Diameter.
  1. Vendor-specific AVPs intended for use with AAA servers should be

defined in terms of RADIUS. Vendor-specific RADIUS attributes

    translate to Diameter (and, hence, to EAP-TTLS) automatically; the
    reverse is not true.  RADIUS vendor-specific attributes use RADIUS
    attribute 26 and include Vendor-ID, vendor-specific attribute
    code, and length; see [RFC2865] for details.

Funk & Blake-Wilson Informational [Page 25] RFC 5281 EAP-TTLSv0 August 2008

11. Tunneled Authentication

 EAP-TTLS permits user authentication information to be tunneled
 within the TLS record layer between client and TTLS server, ensuring
 the security of the authentication information against active and
 passive attack between the client and TTLS server.  The TTLS server
 decrypts and forwards this information to the AAA/H over the AAA
 carrier protocol.
 Any type of password or other authentication may be tunneled.  Also,
 multiple tunneled authentications may be performed.  Normally,
 tunneled authentication is used when the client has not been issued a
 certificate, and the TLS handshake provides only one-way
 authentication of the TTLS server to the client; however, in certain
 cases it may be desired to perform certificate authentication of the
 client during the TLS handshake as well as tunneled user
 authentication afterwards.

11.1. Implicit Challenge

 Certain authentication protocols that use a challenge/response
 mechanism rely on challenge material that is not generated by the
 authentication server, and therefore the material requires special
 handling.
 In CHAP, MS-CHAP, and MS-CHAP-V2, for example, the access point
 issues a challenge to the client, the client then hashes the
 challenge with the password and forwards the response to the access
 point.  The access point then forwards both challenge and response to
 a AAA server.  But because the AAA server did not itself generate the
 challenge, such protocols are susceptible to replay attack.
 If the client were able to create both challenge and response, anyone
 able to observe a CHAP or MS-CHAP exchange could pose as that user,
 even using EAP-TTLS.
 To make these protocols secure under EAP-TTLS, it is necessary to
 provide a mechanism to produce a challenge that the client cannot
 control or predict.  This is accomplished using the same technique
 described above for generating data connection keying material.
 When a challenge-based authentication mechanism is used, both client
 and TTLS server use the pseudo-random function to generate as many
 octets as are required for the challenge, using the constant string
 "ttls challenge", based on the master secret and random values
 established during the handshake:

Funk & Blake-Wilson Informational [Page 26] RFC 5281 EAP-TTLSv0 August 2008

    EAP-TTLS_challenge = PRF-nn(SecurityParameters.master_secret,
                           "ttls challenge",
                           SecurityParameters.client_random +
                           SecurityParameters.server_random);
 The number of octets to be generated (nn) depends on the
 authentication method, and is indicated below for each authentication
 method requiring implicit challenge generation.

11.2. Tunneled Authentication Protocols

 This section describes the methods for tunneling specific
 authentication protocols within EAP-TTLS.
 For the purpose of explication, it is assumed that the TTLS server
 and AAA/H use RADIUS as a AAA carrier protocol between them.
 However, this is not a requirement, and any AAA protocol capable of
 carrying the required information may be used.
 The client determines which authentication protocol will be used via
 the initial AVPs it sends to the server, as described in the
 following sections.
 Note that certain of the authentication protocols described below
 utilize vendor-specific AVPs originally defined for RADIUS.  RADIUS
 and Diameter differ in the encoding of vendor-specific AVPs: RADIUS
 uses the vendor-specific attribute (code 26), while Diameter uses
 setting of the V bit to indicate the presence of Vendor-ID.  The
 RADIUS form of the vendor-specific attribute is always convertible to
 a Diameter AVP with V bit set.  All vendor-specific AVPs described
 below MUST be encoded using the preferred Diameter V bit mechanism;
 that is, the AVP Code of 26 MUST NOT be used to encode vendor-
 specific AVPs within EAP-TTLS.

11.2.1. EAP

 When EAP is the tunneled authentication protocol, each tunneled EAP
 packet between the client and TTLS server is encapsulated in an EAP-
 Message AVP, prior to tunneling via the TLS record layer.
 Note that because Diameter AVPs are not limited to 253 octets of
 data, as are RADIUS attributes, the RADIUS mechanism of concatenating
 multiple EAP-Message attributes to represent a longer-than-253-octet
 EAP packet is not appropriate in EAP-TTLS.  Thus, a tunneled EAP
 packet within a single EAP-TTLS message MUST be contained in a single
 EAP-Message AVP.

Funk & Blake-Wilson Informational [Page 27] RFC 5281 EAP-TTLSv0 August 2008

 The client initiates EAP by tunneling EAP-Response/Identity to the
 TTLS server.  Depending on the requirements specified for the inner
 method, the client MAY now place the actual username in this packet;
 the privacy of the user's identity is now guaranteed by the TLS
 encryption.  This username is typically a Network Access Identifier
 (NAI) [RFC4282]; that is, it is typically in the following format:
    username@realm
 The @realm portion is optional, and is used to allow the TTLS server
 to forward the EAP packet to the appropriate AAA/H.
 Note that the client has two opportunities to specify realms.  The
 first, in the initial, untunneled EAP-Response/Identity packet prior
 to starting EAP-TTLS, indicates the realm of the TTLS server.  The
 second, occurring as part of the EAP exchange within the EAP-TTLS
 tunnel, indicates the realm of the client's home network.  Thus, the
 access point need only know how to route to the realm of the TTLS
 server; the TTLS server is assumed to know how to route to the
 client's home realm.  This serial routing architecture is anticipated
 to be useful in roaming environments, allowing access points or AAA
 proxies behind access points to be configured only with a small
 number of realms.  (Refer to Section 7.3 for additional information
 distinguishing the untunneled and tunneled versions of the EAP-
 Response/Identity packets.)
 Note that TTLS processing of the initial identity exchange is
 different from plain EAP.  The state machine of TTLS is different.
 However, it is expected that the server side is capable of dealing
 with client initiation, because even normal EAP protocol runs are
 client-initiated over AAA.  On the client side, there are various
 implementation techniques to deal with the differences.  Even a
 TTLS-unaware EAP protocol run could be used, if TTLS makes it appear
 as if an EAP-Request/Identity message was actually received.  This is
 similar to what authenticators do when operating between a client and
 a AAA server.
 Upon receipt of the tunneled EAP-Response/Identity, the TTLS server
 forwards it to the AAA/H in a RADIUS Access-Request.
 The AAA/H may immediately respond with an Access-Reject; in which
 case, the TTLS server completes the negotiation by sending an EAP-
 Failure to the access point.  This could occur if the AAA/H does not
 recognize the user's identity, or if it does not support EAP.
 If the AAA/H does recognize the user's identity and does support EAP,
 it responds with an Access-Challenge containing an EAP-Request, with
 the Type and Type-Data fields set according to the EAP protocol with

Funk & Blake-Wilson Informational [Page 28] RFC 5281 EAP-TTLSv0 August 2008

 which the AAA/H wishes to authenticate the client; for example MD5-
 Challenge, One-Time Password (OTP), or Generic Token Card.
 The EAP authentication between client and AAA/H proceeds normally, as
 described in [RFC3748], with the TTLS server acting as a passthrough
 device.  Each EAP-Request sent by the AAA/H in an Access-Challenge is
 tunneled by the TTLS server to the client, and each EAP-Response
 tunneled by the client is decrypted and forwarded by the TTLS server
 to the AAA/H in an Access-Request.
 This process continues until the AAA/H issues an Access-Accept or
 Access-Reject.
 Note that EAP-TTLS does not impose special rules on EAP Notification
 packets; such packets MAY be used within a tunneled EAP exchange
 according to the rules specified in [RFC3748].
 EAP-TTLS provides a reliable transport for the tunneled EAP exchange.
 However, [RFC3748] assumes an unreliable transport for EAP messages
 (see Section 3.1), and provides for silent discard of any EAP packet
 that violates the protocol or fails a method-specific integrity
 check, on the assumption that such a packet is likely a counterfeit
 sent by an attacker.  But since the tunnel provides a reliable
 transport for the inner EAP authentication, errors that would result
 in silent discard according to [RFC3748] presumably represent
 implementation errors when they occur within the tunnel, and SHOULD
 be treated as such in preference to being silently discarded.
 Indeed, silently discarding an EAP message within the tunnel
 effectively puts a halt to the progress of the exchange, and will
 result in long timeouts in cases that ought to result in immediate
 failures.

11.2.2. CHAP

 The CHAP algorithm is described in [RFC1661]; RADIUS attribute
 formats are described in [RFC2865].
 Both client and TTLS server generate 17 octets of challenge material,
 using the constant string "ttls challenge" as described above.  These
 octets are used as follows:
    CHAP-Challenge    [16 octets]
    CHAP Identifier   [1 octet]
 The client initiates CHAP by tunneling User-Name, CHAP-Challenge, and
 CHAP-Password AVPs to the TTLS server.  The CHAP-Challenge value is
 taken from the challenge material.  The CHAP-Password consists of

Funk & Blake-Wilson Informational [Page 29] RFC 5281 EAP-TTLSv0 August 2008

 CHAP Identifier, taken from the challenge material; and CHAP
 response, computed according to the CHAP algorithm.
 Upon receipt of these AVPs from the client, the TTLS server must
 verify that the value of the CHAP-Challenge AVP and the value of the
 CHAP Identifier in the CHAP-Password AVP are equal to the values
 generated as challenge material.  If either item does not match
 exactly, the TTLS server must reject the client.  Otherwise, it
 forwards the AVPs to the AAA/H in an Access-Request.
 The AAA/H will respond with an Access-Accept or Access-Reject.

11.2.3. MS-CHAP

 The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
 formats are described in [RFC2548].
 Both client and TTLS server generate 9 octets of challenge material,
 using the constant string "ttls challenge" as described above.  These
 octets are used as follows:
    MS-CHAP-Challenge  [8 octets]
    Ident              [1 octet]
 The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-
 Challenge and MS-CHAP-Response AVPs to the TTLS server.  The MS-
 CHAP-Challenge value is taken from the challenge material.  The MS-
 CHAP-Response consists of Ident, taken from the challenge material;
 Flags, set according the client preferences; and LM-Response and NT-
 Response, computed according to the MS-CHAP algorithm.
 Upon receipt of these AVPs from the client, the TTLS server MUST
 verify that the value of the MS-CHAP-Challenge AVP and the value of
 the Ident in the client's MS-CHAP-Response AVP are equal to the
 values generated as challenge material.  If either item does not
 match exactly, the TTLS server MUST reject the client.  Otherwise, it
 forwards the AVPs to the AAA/H in an Access-Request.
 The AAA/H will respond with an Access-Accept or Access-Reject.

11.2.4. MS-CHAP-V2

 The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
 formats are described in [RFC2548].
 Both client and TTLS server generate 17 octets of challenge material,
 using the constant string "ttls challenge" as described above.  These
 octets are used as follows:

Funk & Blake-Wilson Informational [Page 30] RFC 5281 EAP-TTLSv0 August 2008

    MS-CHAP-Challenge  [16 octets]
    Ident              [1 octet]
 The client initiates MS-CHAP-V2 by tunneling User-Name, MS-CHAP-
 Challenge, and MS-CHAP2-Response AVPs to the TTLS server.  The MS-
 CHAP-Challenge value is taken from the challenge material.  The MS-
 CHAP2-Response consists of Ident, taken from the challenge material;
 Flags, set to 0; Peer-Challenge, set to a random value; and Response,
 computed according to the MS-CHAP-V2 algorithm.
 Upon receipt of these AVPs from the client, the TTLS server MUST
 verify that the value of the MS-CHAP-Challenge AVP and the value of
 the Ident in the client's MS-CHAP2-Response AVP are equal to the
 values generated as challenge material.  If either item does not
 match exactly, the TTLS server MUST reject the client.  Otherwise, it
 forwards the AVPs to the AAA/H in an Access-Request.
 If the authentication is successful, the AAA/H will respond with an
 Access-Accept containing the MS-CHAP2-Success attribute.  This
 attribute contains a 42-octet string that authenticates the AAA/H to
 the client based on the Peer-Challenge.  The TTLS server tunnels this
 AVP to the client.  Note that the authentication is not yet complete;
 the client must still accept the authentication response of the
 AAA/H.
 Upon receipt of the MS-CHAP2-Success AVP, the client is able to
 authenticate the AAA/H.  If the authentication succeeds, the client
 sends an EAP-TTLS packet to the TTLS server containing no data (that
 is, with a zero-length Data field).  Upon receipt of the empty EAP-
 TTLS packet from the client, the TTLS server considers the MS-CHAP-
 V2 authentication to have succeeded.
 If the authentication fails, the AAA/H will respond with an Access-
 Challenge containing the MS-CHAP-Error attribute.  This attribute
 contains a new Ident and a string with additional information such as
 the error reason and whether a retry is allowed.  The TTLS server
 tunnels this AVP to the client.  If the error reason is an expired
 password and a retry is allowed, the client may proceed to change the
 user's password.  If the error reason is not an expired password or
 if the client does not wish to change the user's password, it simply
 abandons the EAP-TTLS negotiation.
 If the client does wish to change the password, it tunnels MS-CHAP-
 NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the TTLS
 server.  The MS-CHAP2-CPW AVP is derived from the new Ident and
 Challenge received in the MS-CHAP-Error AVP.  The MS-CHAP-Challenge
 AVP simply echoes the new Challenge.

Funk & Blake-Wilson Informational [Page 31] RFC 5281 EAP-TTLSv0 August 2008

 Upon receipt of these AVPs from the client, the TTLS server MUST
 verify that the value of the MS-CHAP-Challenge AVP and the value of
 the Ident in the client's MS-CHAP2-CPW AVP match the values it sent
 in the MS-CHAP-Error AVP.  If either item does not match exactly, the
 TTLS server MUST reject the client.  Otherwise, it forwards the AVPs
 to the AAA/H in an Access-Request.
 If the authentication is successful, the AAA/H will respond with an
 Access-Accept containing the MS-CHAP2-Success attribute.  At this
 point, the negotiation proceeds as described above; the TTLS server
 tunnels the MS-CHAP2-Success to the client, and the client
 authenticates the AAA/H based on this AVP.  Then, the client either
 abandons the negotiation on failure or sends an EAP-TTLS packet to
 the TTLS server containing no data (that is, with a zero-length Data
 field), causing the TTLS server to consider the MS-CHAP-V2
 authentication to have succeeded.
 Note that additional AVPs associated with MS-CHAP-V2 may be sent by
 the AAA/H; for example, MS-CHAP-Domain.  The TTLS server MUST tunnel
 such authentication-related attributes along with the MS-CHAP2-
 Success.

11.2.5. PAP

 The client initiates PAP by tunneling User-Name and User-Password
 AVPs to the TTLS server.
 Normally, in RADIUS, User-Password is padded with nulls to a multiple
 of 16 octets, then encrypted using a shared secret and other packet
 information.
 An EAP-TTLS client, however, does not RADIUS-encrypt the password
 since no such RADIUS variables are available; this is not a security
 weakness since the password will be encrypted via TLS anyway.  The
 client SHOULD, however, null-pad the password to a multiple of 16
 octets, to obfuscate its length.
 Upon receipt of these AVPs from the client, the TTLS server forwards
 them to the AAA/H in a RADIUS Access-Request.  (Note that in the
 Access-Request, the TTLS server must encrypt the User-Password
 attribute using the shared secret between the TTLS server and AAA/H.)
 The AAA/H may immediately respond with an Access-Accept or Access-
 Reject.  The TTLS server then completes the negotiation by sending an
 EAP-Success or EAP-Failure to the access point using the AAA carrier
 protocol.

Funk & Blake-Wilson Informational [Page 32] RFC 5281 EAP-TTLSv0 August 2008

 The AAA/H may also respond with an Access-Challenge.  The TTLS server
 then tunnels the AVPs from the AAA/H's challenge to the client.  Upon
 receipt of these AVPs, the client tunnels User-Name and User-
 Password again, with User-Password containing new information in
 response to the challenge.  This process continues until the AAA/H
 issues an Access-Accept or Access-Reject.
 At least one of the AVPs tunneled to the client upon challenge MUST
 be Reply-Message.  Normally, this is sent by the AAA/H as part of the
 challenge.  However, if the AAA/H has not sent a Reply-Message, the
 TTLS server MUST issue one, with null value.  This allows the client
 to determine that a challenge response is required.
 Note that if the AAA/H includes a Reply-Message as part of an
 Access-Accept or Access-Reject, the TTLS server does not tunnel this
 AVP to the client.  Rather, this AVP and all other AVPs sent by the
 AAA/H as part of Access-Accept or Access-Reject are sent to the
 access point via the AAA carrier protocol.

11.3. Performing Multiple Authentications

 In some cases, it is desirable to perform multiple user
 authentications.  For example, a AAA/H may want first to authenticate
 the user by password, then by token card.
 The AAA/H may perform any number of additional user authentications
 using EAP, simply by issuing a EAP-Request with a new EAP type once
 the previous authentication completes.  Note that each new EAP method
 is subject to negotiation; that is, the client may respond to the EAP
 request for a new EAP type with an EAP-Nak, as described in
 [RFC3748].
 For example, a AAA/H wishing to perform an MD5-Challenge followed by
 Generic Token Card would first issue an EAP-Request/MD5-Challenge and
 receive a response.  If the response is satisfactory, it would then
 issue an EAP-Request/Generic Token Card and receive a response.  If
 that response were also satisfactory, it would accept the user.
 The entire inner EAP exchange comprising multiple authentications is
 considered a single EAP sequence, in that each subsequent request
 MUST contain distinct a EAP Identifier from the previous request,
 even as one authentication completes and another begins.
 The peer identity indicated in the original EAP-Response/Identity
 that initiated the EAP sequence is intended to apply to each of the
 sequential authentications.  In the absence of an application profile
 standard specifying otherwise, additional EAP-Identity exchanges
 SHOULD NOT occur.

Funk & Blake-Wilson Informational [Page 33] RFC 5281 EAP-TTLSv0 August 2008

 The conditions for overall success or failure when multiple
 authentications are used are a matter of policy on client and server;
 thus, either party may require that all inner authentications
 succeed, or that at least one inner authentication succeed, as a
 condition for success of the overall authentication.
 Each EAP method is intended to run to completion.  Should the TTLS
 server abandon a method and start a new one, client behavior is not
 defined in this document and is a matter of client policy.
 Note that it is not always feasible to use the same EAP method twice
 in a row, since it may not be possible to determine when the first
 authentication completes and the new authentication begins if the EAP
 type does not change.  Certain EAP methods, such as EAP-TLS, use a
 Start bit to distinguish the first request, thus allowing each new
 authentication using that type to be distinguished from the previous.
 Other methods, such as EAP-MS-CHAP-V2, terminate in a well-defined
 manner, allowing a second authentication of the same type to commence
 unambiguously.  While use of the same EAP method for multiple
 authentications is relatively unlikely, implementers should be aware
 of the issues and avoid cases that would result in ambiguity.
 Multiple authentications using non-EAP methods or a mixture of EAP
 and non-EAP methods is not defined in this document, nor is it known
 whether such an approach has been implemented.

11.4. Mandatory Tunneled Authentication Support

 To ensure interoperability, in the absence of an application profile
 standard specifying otherwise, an implementation compliant with this
 specification MUST implement EAP as a tunneled authentication method
 and MUST implement MD5-Challenge as an EAP type.  However, such an
 implementation MAY allow the use of EAP, any EAP type, or any other
 tunneled authentication method to be enabled or disabled by
 administrative action on either client or TTLS server.
 In addition, in the absence of an application profile standard
 specifying otherwise, an implementation compliant with this
 specification MUST allow an administrator to configure the use of
 tunneled authentication without the M (Mandatory) bit set on any AVP.

11.5. Additional Suggested Tunneled Authentication Support

 The following information is provided as non-normative guidance based
 on the experience of the authors and reviewers of this specification
 with existing implementations of EAP-TTLSv0.

Funk & Blake-Wilson Informational [Page 34] RFC 5281 EAP-TTLSv0 August 2008

 The following authentication methods are commonly used, and servers
 wishing for broad interoperability across multiple media should
 consider implementing them:
  1. PAP (both for password and token authentication)
  1. MS-CHAP-V2
  1. EAP-MS-CHAP-V2
  1. EAP-GTC

12. Keying Framework

 In compliance with [RFC5247], Session-Id, Peer-Id, and Server-Id are
 here defined.

12.1. Session-Id

 The Session-Id uniquely identifies an authentication exchange between
 the client and TTLS server.  It is defined as follows:
    Session-Id = 0x15 || client.random || server.random

12.2. Peer-Id

 The Peer-Id represents the identity to be used for access control and
 accounting purposes.  When the client presents a certificate as part
 of the TLS handshake, the Peer-Id is determined based on information
 in the certificate, as specified in Section 5.2 of [RFC5216].
 Otherwise, the Peer-Id is null.

12.3. Server-Id

 The Server-Id identifies the TTLS server.  When the TTLS server
 presents a certificate as part of the TLS handshake, the Server-Id is
 determined based on information in the certificate, as specified in
 Section 5.2 of [RFC5216].  Otherwise, the Server-Id is null.

13. AVP Summary

 The following table lists each AVP defined in this document, whether
 the AVP may appear in a packet from server to client ("Request")
 and/or in a packet from client to server ("Response"), and whether
 the AVP MUST be implemented ("MI").

Funk & Blake-Wilson Informational [Page 35] RFC 5281 EAP-TTLSv0 August 2008

 Name              Request  Response    MI
 ---------------------------------------------------
 User-Name                     X
 User-Password                 X
 CHAP-Password                 X
 Reply-Message        X
 CHAP-Challenge                X
 EAP-Message          X        X         X
 MS-CHAP-Response              X
 MS-CHAP-Error        X
 MS-CHAP-NT-Enc-PW             X
 MS-CHAP-Domain       X
 MS-CHAP-Challenge             X
 MS-CHAP2-Response             X
 MS-CHAP2-Success     X
 MS-CHAP2-CPW                  X

14. Security Considerations

14.1. Security Claims

 Pursuant to RFC 3748, security claims for EAP-TTLSv0 are as follows:
 Authentication mechanism: TLS plus arbitrary additional protected
                            authentication(s)
 Ciphersuite negotiation:  Yes
 Mutual authentication:    Yes, in recommended implementation
 Integrity protection:     Yes
 Replay protection:        Yes
 Confidentiality:          Yes
 Key derivation:           Yes
 Key strength:             Up to 384 bits
 Dictionary attack prot.:  Yes
 Fast reconnect:           Yes
 Cryptographic binding:    No
 Session independence:     Yes
 Fragmentation:            Yes
 Channel binding:          No

14.1.1. Authentication Mechanism

 EAP-TTLSv0 utilizes negotiated underlying authentication protocols,
 both in the phase 1 TLS handshake and the phase 2 tunneled
 authentication.  In a typical deployment, at a minimum the TTLS
 server authenticates to the client in phase 1, and the client
 authenticates to the AAA/H server in phase 2.  Phase 1 authentication
 of the TTLS server to the client is typically by certificate; the
 client may optionally authenticate to the TTLS server by certificate

Funk & Blake-Wilson Informational [Page 36] RFC 5281 EAP-TTLSv0 August 2008

 as well.  Phase 2 authentication of the client to the AAA/H server is
 typically by password or security token via an EAP or supported non-
 EAP authentication mechanism; this authentication mechanism may
 provide authentication of the AAA/H server to the client as well
 (mutual authentication).

14.1.2. Ciphersuite Negotiation

 Ciphersuite negotiation is inherited from TLS.

14.1.3. Mutual Authentication

 In the recommended minimum configuration, the TTLS server is
 authenticated to the client in phase 1, and the client and AAA/H
 server mutually authenticate in phase 2.

14.1.4. Integrity Protection

 Integrity protection is inherited from TLS.

14.1.5. Replay Protection

 Replay protection is inherited from TLS.

14.1.6. Confidentiality

 Confidentiality is inherited from TLS.  Note, however, that EAP-
 TTLSv0 contains no provision for encryption of success or failure EAP
 packets.

14.1.7. Key Derivation

 Both MSK and EMSK are derived.  The key derivation PRF is inherited
 from TLS, and cryptographic agility of this mechanism depends on the
 cryptographic agility of the TLS PRF.

14.1.8. Key Strength

 Key strength is limited by the size of the TLS master secret, which
 for versions 1.0 and 1.1 is 48 octets (384 bits).  Effective key
 strength may be less, depending on the attack resistance of the
 negotiated Diffie-Helman (DH) group, certificate RSA/DSA group, etc.
 BCP 86 [RFC3766], Section 5, offers advice on the required RSA or DH
 module and DSA subgroup size in bits, for a given level of attack
 resistance in bits.  For example, a 2048-bit RSA key is recommended
 to provide 128-bit equivalent key strength.  The National Institute
 for Standards and Technology (NIST) also offers advice on appropriate
 key sizes in [SP800-57].

Funk & Blake-Wilson Informational [Page 37] RFC 5281 EAP-TTLSv0 August 2008

14.1.9. Dictionary Attack Protection

 Phase 2 password authentication is protected against eavesdropping
 and therefore against offline dictionary attack by TLS encryption.

14.1.10. Fast Reconnect

 Fast reconnect is provided by TLS session resumption.

14.1.11. Cryptographic Binding

 [MITM] describes a vulnerability that is characteristic of tunneled
 authentication protocols, in which an attacker authenticates as a
 client via a tunneled protocol by posing as an authenticator to a
 legitimate client using a non-tunneled protocol.  When the same proof
 of credentials can be used in both authentications, the attacker
 merely shuttles the credential proof between them.  EAP-TTLSv0 is
 vulnerable to such an attack.  Care should be taken to avoid using
 authentication protocols and associated credentials both as inner
 TTLSv0 methods and as untunneled methods.
 Extensions to EAP-TTLSv0 or a future version of EAP-TTLS should be
 defined to perform a cryptographic binding of keying material
 generated by inner authentication methods and the keying material
 generated by the TLS handshake.  This avoids the man-in-the-middle
 problem when used with key-generating inner methods.  Such an
 extension mechanism has been proposed [TTLS-EXT].

14.1.12. Session Independence

 TLS guarantees the session independence of its master secret, from
 which the EAP-TTLSv0 MSK/EMSK is derived.

14.1.13. Fragmentation

 Provision is made for fragmentation of lengthy EAP packets.

14.1.14. Channel Binding

 Support for channel binding may be added as a future extension, using
 appropriate AVPs.

14.2. Client Anonymity

 Unlike other EAP methods, EAP-TTLS does not communicate a username in
 the clear in the initial EAP-Response/Identity.  This feature is
 designed to support anonymity and location privacy from attackers
 eavesdropping the network path between the client and the TTLS

Funk & Blake-Wilson Informational [Page 38] RFC 5281 EAP-TTLSv0 August 2008

 server.  However, implementers should be aware that other factors --
 both within EAP-TTLS and elsewhere -- may compromise a user's
 identity.  For example, if a user authenticates with a certificate
 during phase 1 of EAP-TTLS, the subject name in the certificate may
 reveal the user's identity.  Outside of EAP-TTLS, the client's fixed
 MAC address, or in the case of wireless connections, the client's
 radio signature, may also reveal information.  Additionally,
 implementers should be aware that a user's identity is not hidden
 from the EAP-TTLS server and may be included in the clear in AAA
 messages between the access point, the EAP-TTLS server, and the AAA/H
 server.
 Note that if a client authenticating with a certificate wishes to
 shield its certificate, and hence its identity, from eavesdroppers,
 it may use the technique described in Section 2.1.4 ("Privacy") of
 [RFC5216], in which the client sends an empty certificate list, the
 TTLS server issues a ServerHello upon completion of the TLS handshake
 to begin a second, encrypted handshake, during which the client will
 send its certificate list.  Note that for this feature to work the
 client must know in advance that the TTLS server supports it.

14.3. Server Trust

 Trust of the server by the client is established via a server
 certificate conveyed during the TLS handshake.  The client should
 have a means of determining which server identities are authorized to
 act as a TTLS server and may be trusted, and should refuse to
 authenticate with servers it does not trust.  The consequence of
 pursuing authentication with a hostile server is exposure of the
 inner authentication to attack; e.g., offline dictionary attack
 against the client password.

14.4. Certificate Validation

 When either client or server presents a certificate as part of the
 TLS handshake, it should include the entire certificate chain minus
 the root to facilitate certificate validation by the other party.
 When either client or server receives a certificate as part of the
 TLS handshake, it should validate the certification path to a trusted
 root.  If intermediate certificates are not provided by the sender,
 the receiver may use cached or pre-configured copies if available, or
 may retrieve them from the Internet if feasible.
 Clients and servers should implement policies related to the Extended
 Key Usage (EKU) extension [RFC5280] of certificates it receives, to
 ensure that the other party's certificate usage conforms to the
 certificate's purpose.  Typically, a client EKU, when present, would

Funk & Blake-Wilson Informational [Page 39] RFC 5281 EAP-TTLSv0 August 2008

 be expected to include id-kp-clientAuth; a server EKU, when present,
 would be expected to include id-kp-serverAuth.  Note that absence of
 the EKU extension or a value of anyExtendedKeyUsage implies absence
 of constraint on the certificate's purpose.

14.5. Certificate Compromise

 Certificates should be checked for revocation to reduce exposure to
 imposture using compromised certificates.
 Checking a server certificate against the most recent revocation list
 during authentication is not always possible for a client, as it may
 not have network access until completion of the authentication.  This
 problem can be alleviated through the use of the Online Certificate
 Status Protocol (OCSP) [RFC2560] during the TLS handshake, as
 described in [RFC4366].

14.6. Forward Secrecy

 With forward secrecy, revelation of a secret does not compromise
 session keys previously negotiated based on that secret.  Thus, when
 the TLS key exchange algorithm provides forward secrecy, if a TTLS
 server certificate's private key is eventually stolen or cracked,
 tunneled user password information will remain secure as long as that
 certificate is no longer in use.  Diffie-Hellman key exchange is an
 example of an algorithm that provides forward secrecy.  A forward
 secrecy algorithm should be considered if attacks against recorded
 authentication or data sessions are considered to pose a significant
 threat.

14.7. Negotiating-Down Attacks

 EAP-TTLS negotiates its own protocol version prior to, and therefore
 outside the security established by the TLS tunnel.  In principle,
 therefore, it is subject to a negotiating-down attack, in which an
 intermediary modifies messages in transit to cause a lower version of
 the protocol to be agreed upon, each party assuming that the other
 does not support as high a version as it actually does.
 The version of the EAP-TTLS protocol described in this document is 0,
 and is therefore not subject to such an attack.  However, any new
 version of the protocol using a higher number than 0 should define a
 mechanism to ensure against such an attack.  One such mechanism might
 be the TTLS server's reiteration of the protocol version that it
 proposed in an AVP within the tunnel, such AVP to be inserted with M
 bit clear even when version 0 is agreed upon.

Funk & Blake-Wilson Informational [Page 40] RFC 5281 EAP-TTLSv0 August 2008

15. Message Sequences

 This section presents EAP-TTLS message sequences for various
 negotiation scenarios.  These examples do not attempt to exhaustively
 depict all possible scenarios.
 It is assumed that RADIUS is the AAA carrier protocol both between
 access point and TTLS server, and between TTLS server and AAA/H.
 EAP packets that are passed unmodified between client and TTLS server
 by the access point are indicated as "passthrough".  AVPs that are
 securely tunneled within the TLS record layer are enclosed in curly
 braces ({}).  Items that are optional are suffixed with question mark
 (?).  Items that may appear multiple times are suffixed with plus
 sign (+).

15.1. Successful Authentication via Tunneled CHAP

 In this example, the client performs one-way TLS authentication of
 the TTLS server.  CHAP is used as a tunneled user authentication
 mechanism.
 client          access point           TTLS server             AAA/H
 ------          ------------           -----------             -----
   EAP-Request/Identity
   <--------------------
   EAP-Response/Identity
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS-Start
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     ClientHello
   -------------------->

Funk & Blake-Wilson Informational [Page 41] RFC 5281 EAP-TTLSv0 August 2008

                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS:
                             ServerHello
                             Certificate
                             ServerKeyExchange
                             ServerHelloDone
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     ClientKeyExchange
     ChangeCipherSpec
     Finished
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS:
                             ChangeCipherSpec
                             Finished
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     {User-Name}
     {CHAP-Challenge}
     {CHAP-Password}
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->

Funk & Blake-Wilson Informational [Page 42] RFC 5281 EAP-TTLSv0 August 2008

                                           RADIUS Access-Request:
                                             User-Name
                                             CHAP-Challenge
                                             CHAP-Password
                                           -------------------->
                                           RADIUS Access-Accept
                                           <--------------------
                         RADIUS Access-Accept:
                           EAP-Success
                         <--------------------
   EAP-Success
   <--------------------

15.2. Successful Authentication via Tunneled EAP/MD5-Challenge

 In this example, the client performs one-way TLS authentication of
 the TTLS server and EAP/MD5-Challenge is used as a tunneled user
 authentication mechanism.
 client          access point           TTLS server             AAA/H
 ------          ------------           -----------             -----
   EAP-Request/Identity
   <--------------------
   EAP-Response/Identity
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS-Start
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     ClientHello
   -------------------->

Funk & Blake-Wilson Informational [Page 43] RFC 5281 EAP-TTLSv0 August 2008

                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS:
                             ServerHello
                             Certificate
                             ServerKeyExchange
                             ServerHelloDone
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     ClientKeyExchange
     ChangeCipherSpec
     Finished
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS:
                             ChangeCipherSpec
                             Finished
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     {EAP-Response/Identity}
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                                           RADIUS Access-Request:
                                             EAP-Response/Identity
                                           -------------------->

Funk & Blake-Wilson Informational [Page 44] RFC 5281 EAP-TTLSv0 August 2008

                                           RADIUS Access-Challenge
                                             EAP-Request/
                                                 MD5-Challenge
                                           <--------------------
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS:
                             {EAP-Request/MD5-Challenge}
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     {EAP-Response/MD5-Challenge}
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                                           RADIUS Access-Challenge
                                             EAP-Response/
                                                 MD5-Challenge
                                           -------------------->
                                           RADIUS Access-Accept
                                           <--------------------
                         RADIUS Access-Accept:
                           EAP-Success
                         <--------------------
   EAP-Success
   <--------------------

Funk & Blake-Wilson Informational [Page 45] RFC 5281 EAP-TTLSv0 August 2008

15.3. Successful Session Resumption

 In this example, the client and server resume a previous TLS session.
 The ID of the session to be resumed is sent as part of the
 ClientHello, and the server agrees to resume this session by sending
 the same session ID as part of ServerHello.
 client          access point           TTLS server             AAA/H
 ------          ------------           -----------             -----
   EAP-Request/Identity
   <--------------------
   EAP-Response/Identity
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS-Start
                         <--------------------
   EAP-Request passthrough
   <--------------------
   EAP-Response/TTLS:
     ClientHello
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Challenge:
                           EAP-Request/TTLS:
                             ServerHello
                             ChangeCipherSpec
                             Finished
                         <--------------------
   EAP-Request passthrough
   <--------------------

Funk & Blake-Wilson Informational [Page 46] RFC 5281 EAP-TTLSv0 August 2008

   EAP-Response/TTLS:
     ChangeCipherSpec
     Finished
   -------------------->
                         RADIUS Access-Request:
                           EAP-Response passthrough
                         -------------------->
                         RADIUS Access-Accept:
                           EAP-Success
                         <--------------------
   EAP-Success
   <--------------------

16. IANA Considerations

 IANA has assigned the number 21 (decimal) as the method type of the
 EAP-TTLS protocol.  Mechanisms for defining new RADIUS and Diameter
 AVPs and AVP values are outlined in [RFC2865] and [RFC3588],
 respectively.  No additional IANA registrations are specifically
 contemplated in this document.
 Section 11 of this document specifies how certain authentication
 mechanisms may be performed within the secure tunnel established by
 EAP-TTLS.  New mechanisms and other functions MAY also be performed
 within this tunnel.  Where such extensions use AVPs that are not
 vendor-specific, their semantics must be specified in new RFCs; that
 is, there are TTLS-specific processing rules related to the use of
 each individual AVP, even though such AVPs have already been defined
 for RADIUS or DIAMETER.
 This specification requires the creation of a new registry -- EAP-
 TTLS AVP Usage -- to be managed by IANA, listing each non-vendor-
 specific RADIUS/Diameter AVP that has been defined for use within
 EAP-TTLS, along with a reference to the RFC or other document that
 specifies its semantics.  The initial list of AVPs shall be those
 listed in Section 13 of this document.  The purpose of this registry
 is to avoid potential ambiguity resulting from the same AVP being
 utilized in different functional contexts.  This registry does not
 assign numbers to AVPs, as the AVP numbers are assigned out of the
 RADIUS and Diameter namespaces as outlined in [RFC2865] and
 [RFC3588].  Only top-level AVPs -- that is, AVPs not encapsulated
 within Grouped AVPs -- will be registered.  AVPs should be added to
 this registry based on IETF Review as defined in [RFC5226].

Funk & Blake-Wilson Informational [Page 47] RFC 5281 EAP-TTLSv0 August 2008

17. Acknowledgements

 Thanks to Bernard Aboba, Jari Arkko, Lakshminath Dondeti, Stephen
 Hanna, Ryan Hurst, Avi Lior, and Gabriel Montenegro for careful
 reviews and useful comments.

18. References

18.1. Normative References

 [RFC1661]   Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
             STD 51, RFC 1661, July 1994.
 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
             RFC 2246, January 1999.
 [RFC2433]   Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
             RFC 2433, October 1998.
 [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
             May 2008.
 [RFC2548]   Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
             RFC 2548, March 1999.
 [RFC2759]   Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
             2759, January 2000.
 [RFC2865]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
             "Remote Authentication Dial In User Service (RADIUS)",
             RFC 2865, June 2000.
 [RFC3232]   Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is
             Replaced by an On-line Database", RFC 3232, January 2002.
 [RFC3588]   Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
             Arkko, "Diameter Base Protocol", RFC 3588, September
             2003.
 [RFC3748]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
             Levkowetz, Ed., "Extensible Authentication Protocol
             (EAP)", RFC 3748, June 2004.

Funk & Blake-Wilson Informational [Page 48] RFC 5281 EAP-TTLSv0 August 2008

 [RFC4282]   Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
             Network Access Identifier", RFC 4282, December 2005.
 [RFC4346]   Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 [RFC5216]   Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
             Authentication Protocol", RFC 5216, March 2008.
 [RFC5247]   Aboba, B., Simon, D., and P. Eronen, "Extensible
             Authentication Protocol (EAP) Key Management Framework",
             RFC 5247, August 2008.

18.2. Informative References

 [802.1X]    Institute of Electrical and Electronics Engineers, "Local
             and Metropolitan Area Networks: Port-Based Network Access
             Control", IEEE Standard 802.1X-2004, December 2004.
 [802.11]    Institute of Electrical and Electronics Engineers,
             "Information technology - Telecommunications and
             information exchange between systems - Local and
             metropolitan area networks - Specific Requirements Part
             11:  Wireless LAN Medium Access Control (MAC) and
             Physical Layer (PHY) Specifications", IEEE Standard
             802.11, 2007.
 [TTLS-EXT]  Hanna, S. and P. Funk, "Key Agility Extensions for EAP-
             TTLSv0", Work in Progress, September 2007.
 [RFC2560]   Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
             Adams, "X.509 Internet Public Key Infrastructure Online
             Certificate Status Protocol - OCSP", RFC 2560, June 1999.
 [RFC5280]   Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
             Housley, R., and W. Polk, "Internet X.509 Public Key
             Infrastructure Certificate and Certificate Revocation
             List (CRL) Profile", RFC 5280, May 2008.
 [RFC3766]   Orman, H. and P. Hoffman, "Determining Strengths For
             Public Keys Used For Exchanging Symmetric Keys", BCP 86,
             RFC 3766, April 2004.
 [RFC4366]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
             J., and T. Wright, "Transport Layer Security (TLS)
             Extensions", RFC 4366, April 2006.

Funk & Blake-Wilson Informational [Page 49] RFC 5281 EAP-TTLSv0 August 2008

 [MITM]      Asokan, N., Niemi, V., and Nyberg, K., "Man-in-the-
             Middle in Tunneled Authentication",
             http://www.saunalahti.fi/~asokan/research/mitm.html,
             Nokia Research Center, Finland, October 24, 2002.
 [SP800-57]  National Institute of Standards and Technology,
             "Recommendation for Key Management", Special Publication
             800-57, May 2006.

Authors' Addresses

 Paul Funk
 43 Linnaean St.
 Cambridge, MA 02138
 EMail: PaulFunk@alum.mit.edu
 Simon Blake-Wilson
 SafeNet
 Amstelveenseweg 88-90
 1054XV, Amsterdam
 The Netherlands
 EMail: sblakewilson@nl.safenet-inc.com

Funk & Blake-Wilson Informational [Page 50] RFC 5281 EAP-TTLSv0 August 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Funk & Blake-Wilson Informational [Page 51]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5281.txt · Last modified: 2008/08/14 22:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki