tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5281

 Errata 
Informational
Pages: 51
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec-eap

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

Part 1 of 3, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
   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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
   With the advent of wireless connectivity, however, the situation
   changes dramatically:

   -  Wireless connections are considerably more susceptible to
      eavesdropping and man-in-the-middle attacks.  These attacks may
      enable dictionary attacks against low-entropy passwords.  In
      addition, they may enable channel hijacking, in which an attacker
      gains fraudulent access by seizing control of the communications
      channel after authentication is complete.

   -  Existing authentication protocols often begin by exchanging the
      client's username in the clear.  In the context of eavesdropping
      on the wireless channel, this can compromise the client's
      anonymity and locational privacy.

   -  Often in wireless networks, the access point does not reside in
      the administrative domain of the service provider with which the
      user has a relationship.  For example, the access point may reside
      in an airport, coffee shop, or hotel in order to provide public
      access via 802.11 [802.11].  Even if password authentications are
      protected in the wireless leg, they may still be susceptible to
      eavesdropping within the untrusted wired network of the access
      point.

   -  In the traditional wired world, the user typically intentionally
      connects with a particular service provider by dialing an
      associated phone number; that service provider may be required to
      route an authentication to the user's home domain.  In a wireless
      network, however, the user does not get to choose an access
      domain, and must connect with whichever access point is nearby;
      providing for the routing of the authentication from an arbitrary
      access point to the user's home domain may pose a challenge.

   Thus, the authentication requirements for a wireless environment that
   EAP-TTLS attempts to address can be summarized as follows:

   -  Legacy password protocols must be supported, to allow easy
      deployment against existing authentication databases.

   -  Password-based information must not be observable in the
      communications channel between the client node and a trusted
      service provider, to protect the user against dictionary attacks.

   -  The user's identity must not be observable in the communications
      channel between the client node and a trusted service provider, to
      protect the user against surveillance, undesired acquisition of
      marketing information, and the like.

Top      ToC       Page 7 
   -  The authentication process must result in the distribution of
      shared keying information to the client and access point to permit
      encryption and validation of the wireless data connection
      subsequent to authentication, to secure it against eavesdroppers
      and prevent channel hijacking.

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

Top      ToC       Page 8 
      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.

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
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.)   |
   +-----------------------------------------------------------+

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
   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

Top      ToC       Page 16 
   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.

Top      ToC       Page 17 
   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:

   -  Successful session resumption, with no additional information
      exchange required,

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

Top      ToC       Page 18 
   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:

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

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

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

Top      ToC       Page 19 
   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.



(page 19 continued on part 2)

Next RFC Part