tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7170

Proposed STD
Pages: 101
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: EMU

Tunnel Extensible Authentication Protocol (TEAP) Version 1

Part 1 of 4, p. 1 to 24
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                           H. Zhou
Request for Comments: 7170                                 N. Cam-Winget
Category: Standards Track                                     J. Salowey
ISSN: 2070-1721                                            Cisco Systems
                                                                S. Hanna
                                                   Infineon Technologies
                                                                May 2014


       Tunnel Extensible Authentication Protocol (TEAP) Version 1

Abstract

   This document defines the Tunnel Extensible Authentication Protocol
   (TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
   secure communication between a peer and a server by using the
   Transport Layer Security (TLS) protocol to establish a mutually
   authenticated tunnel.  Within the tunnel, TLV objects are used to
   convey authentication-related data between the EAP peer and the EAP
   server.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7170.

Page 2 
Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1.  Specification Requirements  . . . . . . . . . . . . . . .   5
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Architectural Model . . . . . . . . . . . . . . . . . . .   7
     2.2.  Protocol-Layering Model . . . . . . . . . . . . . . . . .   8
   3.  TEAP Protocol . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Version Negotiation . . . . . . . . . . . . . . . . . . .   9
     3.2.  TEAP Authentication Phase 1: Tunnel Establishment . . . .  10
       3.2.1.  TLS Session Resume Using Server State . . . . . . . .  11
       3.2.2.  TLS Session Resume Using a PAC  . . . . . . . . . . .  12
       3.2.3.  Transition between Abbreviated and Full TLS Handshake  13
     3.3.  TEAP Authentication Phase 2: Tunneled Authentication  . .  14
       3.3.1.  EAP Sequences . . . . . . . . . . . . . . . . . . . .  14
       3.3.2.  Optional Password Authentication  . . . . . . . . . .  15
       3.3.3.  Protected Termination and Acknowledged Result
               Indication  . . . . . . . . . . . . . . . . . . . . .  15
     3.4.  Determining Peer-Id and Server-Id . . . . . . . . . . . .  16
     3.5.  TEAP Session Identifier . . . . . . . . . . . . . . . . .  17
     3.6.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  17
       3.6.1.  Outer-Layer Errors  . . . . . . . . . . . . . . . . .  18
       3.6.2.  TLS Layer Errors  . . . . . . . . . . . . . . . . . .  18
       3.6.3.  Phase 2 Errors  . . . . . . . . . . . . . . . . . . .  19
     3.7.  Fragmentation . . . . . . . . . . . . . . . . . . . . . .  19
     3.8.  Peer Services . . . . . . . . . . . . . . . . . . . . . .  20
       3.8.1.  PAC Provisioning  . . . . . . . . . . . . . . . . . .  21
       3.8.2.  Certificate Provisioning within the Tunnel  . . . . .  22
       3.8.3.  Server Unauthenticated Provisioning Mode  . . . . . .  23
       3.8.4.  Channel Binding . . . . . . . . . . . . . . . . . . .  23

Top      ToC       Page 3 
   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  24
     4.1.  TEAP Message Format . . . . . . . . . . . . . . . . . . .  24
     4.2.  TEAP TLV Format and Support . . . . . . . . . . . . . . .  26
       4.2.1.  General TLV Format  . . . . . . . . . . . . . . . . .  28
       4.2.2.  Authority-ID TLV  . . . . . . . . . . . . . . . . . .  29
       4.2.3.  Identity-Type TLV . . . . . . . . . . . . . . . . . .  30
       4.2.4.  Result TLV  . . . . . . . . . . . . . . . . . . . . .  31
       4.2.5.  NAK TLV . . . . . . . . . . . . . . . . . . . . . . .  32
       4.2.6.  Error TLV . . . . . . . . . . . . . . . . . . . . . .  33
       4.2.7.  Channel-Binding TLV . . . . . . . . . . . . . . . . .  36
       4.2.8.  Vendor-Specific TLV . . . . . . . . . . . . . . . . .  37
       4.2.9.  Request-Action TLV  . . . . . . . . . . . . . . . . .  38
       4.2.10. EAP-Payload TLV . . . . . . . . . . . . . . . . . . .  40
       4.2.11. Intermediate-Result TLV . . . . . . . . . . . . . . .  41
       4.2.12. PAC TLV Format  . . . . . . . . . . . . . . . . . . .  42
         4.2.12.1.  Formats for PAC Attributes . . . . . . . . . . .  43
         4.2.12.2.  PAC-Key  . . . . . . . . . . . . . . . . . . . .  44
         4.2.12.3.  PAC-Opaque . . . . . . . . . . . . . . . . . . .  44
         4.2.12.4.  PAC-Info . . . . . . . . . . . . . . . . . . . .  45
         4.2.12.5.  PAC-Acknowledgement TLV  . . . . . . . . . . . .  47
         4.2.12.6.  PAC-Type TLV . . . . . . . . . . . . . . . . . .  48
       4.2.13. Crypto-Binding TLV  . . . . . . . . . . . . . . . . .  48
       4.2.14. Basic-Password-Auth-Req TLV . . . . . . . . . . . . .  51
       4.2.15. Basic-Password-Auth-Resp TLV  . . . . . . . . . . . .  52
       4.2.16. PKCS#7 TLV  . . . . . . . . . . . . . . . . . . . . .  53
       4.2.17. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . .  54
       4.2.18. Trusted-Server-Root TLV . . . . . . . . . . . . . . .  55
     4.3.  TLV Rules . . . . . . . . . . . . . . . . . . . . . . . .  56
       4.3.1.  Outer TLVs  . . . . . . . . . . . . . . . . . . . . .  57
       4.3.2.  Inner TLVs  . . . . . . . . . . . . . . . . . . . . .  57
   5.  Cryptographic Calculations  . . . . . . . . . . . . . . . . .  58
     5.1.  TEAP Authentication Phase 1: Key Derivations  . . . . . .  58
     5.2.  Intermediate Compound Key Derivations . . . . . . . . . .  59
     5.3.  Computing the Compound MAC  . . . . . . . . . . . . . . .  61
     5.4.  EAP Master Session Key Generation . . . . . . . . . . . .  61
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  62
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  66
     7.1.  Mutual Authentication and Integrity Protection  . . . . .  67
     7.2.  Method Negotiation  . . . . . . . . . . . . . . . . . . .  67
     7.3.  Separation of Phase 1 and Phase 2 Servers . . . . . . . .  67
     7.4.  Mitigation of Known Vulnerabilities and Protocol
           Deficiencies  . . . . . . . . . . . . . . . . . . . . . .  68
       7.4.1.  User Identity Protection and Verification . . . . . .  69
       7.4.2.  Dictionary Attack Resistance  . . . . . . . . . . . .  70
       7.4.3.  Protection against Man-in-the-Middle Attacks  . . . .  70
       7.4.4.  PAC Binding to User Identity  . . . . . . . . . . . .  71

Top      ToC       Page 4 
     7.5.  Protecting against Forged Cleartext EAP Packets . . . . .  71
     7.6.  Server Certificate Validation . . . . . . . . . . . . . .  72
     7.7.  Tunnel PAC Considerations . . . . . . . . . . . . . . . .  72
     7.8.  Security Claims . . . . . . . . . . . . . . . . . . . . .  73
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  74
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  75
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  75
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  76
   Appendix A.  Evaluation against Tunnel-Based EAP Method
                Requirements . . . . . . . . . . . . . . . . . . . .  79
     A.1.  Requirement 4.1.1: RFC Compliance . . . . . . . . . . . .  79
     A.2.  Requirement 4.2.1: TLS Requirements . . . . . . . . . . .  79
     A.3.  Requirement 4.2.1.1.1: Ciphersuite Negotiation  . . . . .  79
     A.4.  Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms   79
     A.5.  Requirement 4.2.1.1.3: Tunnel Authentication and Key
           Establishment . . . . . . . . . . . . . . . . . . . . . .  79
     A.6.  Requirement 4.2.1.2: Tunnel Replay Protection . . . . . .  79
     A.7.  Requirement 4.2.1.3: TLS Extensions . . . . . . . . . . .  80
     A.8.  Requirement 4.2.1.4: Peer Identity Privacy  . . . . . . .  80
     A.9.  Requirement 4.2.1.5: Session Resumption . . . . . . . . .  80
     A.10. Requirement 4.2.2: Fragmentation  . . . . . . . . . . . .  80
     A.11. Requirement 4.2.3: Protection of Data External to Tunnel   80
     A.12. Requirement 4.3.1: Extensible Attribute Types . . . . . .  80
     A.13. Requirement 4.3.2: Request/Challenge Response Operation .  80
     A.14. Requirement 4.3.3: Indicating Criticality of Attributes .  80
     A.15. Requirement 4.3.4: Vendor-Specific Support  . . . . . . .  81
     A.16. Requirement 4.3.5: Result Indication  . . . . . . . . . .  81
     A.17. Requirement 4.3.6: Internationalization of Display
           Strings . . . . . . . . . . . . . . . . . . . . . . . . .  81
     A.18. Requirement 4.4: EAP Channel-Binding Requirements . . . .  81
     A.19. Requirement 4.5.1.1: Confidentiality and Integrity  . . .  81
     A.20. Requirement 4.5.1.2: Authentication of Server . . . . . .  81
     A.21. Requirement 4.5.1.3: Server Certificate Revocation
           Checking  . . . . . . . . . . . . . . . . . . . . . . . .  81
     A.22. Requirement 4.5.2: Internationalization . . . . . . . . .  81
     A.23. Requirement 4.5.3: Metadata . . . . . . . . . . . . . . .  82
     A.24. Requirement 4.5.4: Password Change  . . . . . . . . . . .  82
     A.25. Requirement 4.6.1: Method Negotiation . . . . . . . . . .  82
     A.26. Requirement 4.6.2: Chained Methods  . . . . . . . . . . .  82
     A.27. Requirement 4.6.3: Cryptographic Binding with the TLS
           Tunnel  . . . . . . . . . . . . . . . . . . . . . . . . .  82
     A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication  . .  82
     A.29. Requirement 4.6.5: Method Metadata  . . . . . . . . . . .  82
   Appendix B.  Major Differences from EAP-FAST  . . . . . . . . . .  83
   Appendix C.  Examples . . . . . . . . . . . . . . . . . . . . . .  83
     C.1.  Successful Authentication . . . . . . . . . . . . . . . .  83
     C.2.  Failed Authentication . . . . . . . . . . . . . . . . . .  85
     C.3.  Full TLS Handshake Using Certificate-Based Ciphersuite  .  86

Top      ToC       Page 5 
     C.4.  Client Authentication during Phase 1 with Identity
           Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  88
     C.5.  Fragmentation and Reassembly  . . . . . . . . . . . . . .  89
     C.6.  Sequence of EAP Methods . . . . . . . . . . . . . . . . .  91
     C.7.  Failed Crypto-Binding . . . . . . . . . . . . . . . . . .  94
     C.8.  Sequence of EAP Method with Vendor-Specific TLV Exchange   95
     C.9.  Peer Requests Inner Method after Server Sends Result TLV   97
     C.10. Channel Binding . . . . . . . . . . . . . . . . . . . . .  99

1.  Introduction

   A tunnel-based Extensible Authentication Protocol (EAP) method is an
   EAP method that establishes a secure tunnel and executes other EAP
   methods under the protection of that secure tunnel.  A tunnel-based
   EAP method can be used in any lower-layer protocol that supports EAP
   authentication.  There are several existing tunnel-based EAP methods
   that use Transport Layer Security (TLS) [RFC5246] to establish the
   secure tunnel.  EAP methods supporting this include Protected EAP
   (PEAP) [PEAP], EAP Tunneled Transport Layer Security (EAP-TTLS)
   [RFC5281], and EAP Flexible Authentication via Secure Tunneling (EAP-
   FAST) [RFC4851].  However, they all are either vendor-specific or
   informational, and the industry calls for a Standards Track tunnel-
   based EAP method.  [RFC6678] outlines the list of requirements for a
   standard tunnel-based EAP method.

   Since its introduction, EAP-FAST [RFC4851] has been widely adopted in
   a variety of devices and platforms.  It has been adopted by the EMU
   working group as the basis for the standard tunnel-based EAP method.
   This document describes the Tunnel Extensible Authentication Protocol
   (TEAP) version 1, based on EAP-FAST [RFC4851] with some minor changes
   to meet the requirements outlined in [RFC6678] for a standard tunnel-
   based EAP method.

1.1.  Specification Requirements

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

Top      ToC       Page 6 
1.2.  Terminology

   Much of the terminology in this document comes from [RFC3748].
   Additional terms are defined below:

   Protected Access Credential (PAC)

      Credentials distributed to a peer for future optimized network
      authentication.  The PAC consists of a minimum of two components:
      a shared secret and an opaque element.  The shared secret
      component contains the pre-shared key between the peer and the
      authentication server.  The opaque part is provided to the peer
      and is presented to the authentication server when the peer wishes
      to obtain access to network resources.  The opaque element and
      shared secret are used with TLS stateless session resumption
      defined in [RFC5077] to establish a protected TLS session.  The
      secret key and opaque part may be distributed using [RFC5077]
      messages or using TLVs within the TEAP tunnel.  Finally, a PAC may
      optionally include other information that may be useful to the
      peer.

   Type-Length-Value (TLV)

      The TEAP protocol utilizes objects in TLV format.  The TLV format
      is defined in Section 4.2.

2.  Protocol Overview

   TEAP authentication occurs in two phases after the initial EAP
   Identity request/response exchange.  In the first phase, TEAP employs
   the TLS [RFC5246] handshake to provide an authenticated key exchange
   and to establish a protected tunnel.  Once the tunnel is established,
   the second phase begins with the peer and server engaging in further
   conversations to establish the required authentication and
   authorization policies.  TEAP makes use of TLV objects to carry out
   the inner authentication, results, and other information, such as
   channel-binding information.

   TEAP makes use of the TLS SessionTicket extension [RFC5077], which
   supports TLS session resumption without requiring session-specific
   state stored at the server.  In this document, the SessionTicket is
   referred to as the Protected Access Credential opaque data (or PAC-
   Opaque).  The PAC-Opaque may be distributed through the use of the
   NewSessionTicket message or through a mechanism that uses TLVs within
   Phase 2 of TEAP.  The secret key used to resume the session in TEAP
   is referred to as the Protected Access Credential key (or PAC-Key).
   When the NewSessionTicket message is used to distribute the PAC-
   Opaque, the PAC-Key is the master secret for the session.  If TEAP

Top      ToC       Page 7 
   Phase 2 is used to distribute the PAC-Opaque, then the PAC-Key is
   distributed along with the PAC-Opaque.  TEAP implementations MUST
   support the [RFC5077] mechanism for distributing a PAC-Opaque, and it
   is RECOMMENDED that implementations support the capability to
   distribute the ticket and secret key within the TEAP tunnel.

   The TEAP conversation is used to establish or resume an existing
   session to typically establish network connectivity between a peer
   and the network.  Upon successful execution of TEAP, the EAP peer and
   EAP server both derive strong session key material that can then be
   communicated to the network access server (NAS) for use in
   establishing a link-layer security association.

2.1.  Architectural Model

   The network architectural model for TEAP usage is shown below:

    +----------+      +----------+      +----------+      +----------+
    |          |      |          |      |          |      |  Inner   |
    |   Peer   |<---->|  Authen- |<---->|   TEAP   |<---->|  Method  |
    |          |      |  ticator |      |  server  |      |  server  |
    |          |      |          |      |          |      |          |
    +----------+      +----------+      +----------+      +----------+

                         TEAP Architectural Model

   The entities depicted above are logical entities and may or may not
   correspond to separate network components.  For example, the TEAP
   server and inner method server might be a single entity; the
   authenticator and TEAP server might be a single entity; or the
   functions of the authenticator, TEAP server, and inner method server
   might be combined into a single physical device.  For example,
   typical IEEE 802.11 deployments place the authenticator in an access
   point (AP) while a RADIUS server may provide the TEAP and inner
   method server components.  The above diagram illustrates the division
   of labor among entities in a general manner and shows how a
   distributed system might be constructed; however, actual systems
   might be realized more simply.  The security considerations in
   Section 7.3 provide an additional discussion of the implications of
   separating the TEAP server from the inner method server.

Top      ToC       Page 8 
2.2.  Protocol-Layering Model

   TEAP packets are encapsulated within EAP; EAP in turn requires a
   transport protocol.  TEAP packets encapsulate TLS, which is then used
   to encapsulate user authentication information.  Thus, TEAP messaging
   can be described using a layered model, where each layer encapsulates
   the layer above it.  The following diagram clarifies the relationship
   between protocols:

    +---------------------------------------------------------------+
    |       Inner EAP Method     |     Other TLV information        |
    |---------------------------------------------------------------|
    |                 TLV Encapsulation (TLVs)                      |
    |---------------------------------------------------------------|
    |                TLS         |     Optional Outer TLVs          |
    |---------------------------------------------------------------|
    |                         TEAP                                  |
    |---------------------------------------------------------------|
    |                         EAP                                   |
    |---------------------------------------------------------------|
    |    Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.)    |
    +---------------------------------------------------------------+

                          Protocol-Layering Model

   The TLV layer is a payload with TLV objects as defined in
   Section 4.2.  The TLV objects are used to carry arbitrary parameters
   between an EAP peer and an EAP server.  All conversations in the TEAP
   protected tunnel are encapsulated in a TLV layer.

   TEAP packets may include TLVs both inside and outside the TLS tunnel.
   The term "Outer TLVs" is used to refer to optional TLVs outside the
   TLS tunnel, which are only allowed in the first two messages in the
   TEAP protocol.  That is the first EAP-server-to-peer message and
   first peer-to-EAP-server message.  If the message is fragmented, the
   whole set of messages is counted as one message.  The term "Inner
   TLVs" is used to refer to TLVs sent within the TLS tunnel.  In TEAP
   Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no
   Inner TLVs are used.  In Phase 2 of the TEAP conversation, TLS
   records may encapsulate zero or more Inner TLVs, but no Outer TLVs.

   Methods for encapsulating EAP within carrier protocols are already
   defined.  For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to
   transport EAP between the peer and the authenticator; RADIUS
   [RFC3579] or Diameter [RFC4072] may be used to transport EAP between
   the authenticator and the EAP server.

Top      ToC       Page 9 
3.  TEAP Protocol

   The operation of the protocol, including Phase 1 and Phase 2, is the
   topic of this section.  The format of TEAP messages is given in
   Section 4, and the cryptographic calculations are given in Section 5.

3.1.  Version Negotiation

   TEAP packets contain a 3-bit Version field, following the TLS Flags
   field, which enables future TEAP implementations to be backward
   compatible with previous versions of the protocol.  This
   specification documents the TEAP version 1 protocol; implementations
   of this specification MUST use a Version field set to 1.

   Version negotiation proceeds as follows:

   1.   In the first EAP-Request sent with EAP type=TEAP, the EAP server
        MUST set the Version field to the highest version it supports.

   2a.  If the EAP peer supports this version of the protocol, it
        responds with an EAP-Response of EAP type=TEAP, including the
        version number proposed by the TEAP server.

   2b.  If the TEAP peer does not support the proposed version but
        supports a lower version, it responds with an EAP-Response of
        EAP type=TEAP and sets the Version field to its highest
        supported version.

   2c.  If the TEAP peer only supports versions higher than the version
        proposed by the TEAP server, then use of TEAP will not be
        possible.  In this case, the TEAP peer sends back an EAP-Nak
        either to negotiate a different EAP type or to indicate no other
        EAP types are available.

   3a.  If the TEAP server does not support the version number proposed
        by the TEAP peer, it MUST either terminate the conversation with
        an EAP Failure or negotiate a new EAP type.

   3b.  If the TEAP server does support the version proposed by the TEAP
        peer, then the conversation continues using the version proposed
        by the TEAP peer.

   The version negotiation procedure guarantees that the TEAP peer and
   server will agree to the latest version supported by both parties.
   If version negotiation fails, then use of TEAP will not be possible,
   and another mutually acceptable EAP method will need to be negotiated
   if authentication is to proceed.

Top      ToC       Page 10 
   The TEAP version is not protected by TLS and hence can be modified in
   transit.  In order to detect a modification of the TEAP version, the
   peers MUST exchange the TEAP version number received during version
   negotiation using the Crypto-Binding TLV described in Section 4.2.13.
   The receiver of the Crypto-Binding TLV MUST verify that the version
   received in the Crypto-Binding TLV matches the version sent by the
   receiver in the TEAP version negotiation.  If the Crypto-Binding TLV
   fails to be validated, then it is a fatal error and is handled as
   described in Section 3.6.3.

3.2.  TEAP Authentication Phase 1: Tunnel Establishment

   TEAP relies on the TLS handshake [RFC5246] to establish an
   authenticated and protected tunnel.  The TLS version offered by the
   peer and server MUST be TLS version 1.2 [RFC5246] or later.  This
   version of the TEAP implementation MUST support the following TLS
   ciphersuites:

      TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]

      TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246]

   This version of the TEAP implementation SHOULD support the following
   TLS ciphersuite:

      TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246]

   Other ciphersuites MAY be supported.  It is REQUIRED that anonymous
   ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only
   be used in the case when the inner authentication method provides
   mutual authentication, key generation, and resistance to man-in-the-
   middle and dictionary attacks.  TLS ciphersuites that do not provide
   confidentiality MUST NOT be used.  During the TEAP Phase 1
   conversation, the TEAP endpoints MAY negotiate TLS compression.
   During TLS tunnel establishment, TLS extensions MAY be used.  For
   instance, the Certificate Status Request extension [RFC6066] and the
   Multiple Certificate Status Request extension [RFC6961] can be used
   to leverage a certificate-status protocol such as Online Certificate
   Status Protocol (OCSP) [RFC6960] to check the validity of server
   certificates.  TLS renegotiation indications defined in RFC 5746
   [RFC5746] MUST be supported.

   The EAP server initiates the TEAP conversation with an EAP request
   containing a TEAP/Start packet.  This packet includes a set Start (S)
   bit, the TEAP version as specified in Section 3.1, and an authority
   identity TLV.  The TLS payload in the initial packet is empty.  The
   authority identity TLV (Authority-ID TLV) is used to provide the peer
   a hint of the server's identity that may be useful in helping the

Top      ToC       Page 11 
   peer select the appropriate credential to use.  Assuming that the
   peer supports TEAP, the conversation continues with the peer sending
   an EAP-Response packet with EAP type of TEAP with the Start (S) bit
   clear and the version as specified in Section 3.1.  This message
   encapsulates one or more TLS handshake messages.  If the TEAP version
   negotiation is successful, then the TEAP conversation continues until
   the EAP server and EAP peer are ready to enter Phase 2.  When the
   full TLS handshake is performed, then the first payload of TEAP Phase
   2 MAY be sent along with a server-finished handshake message to
   reduce the number of round trips.

   TEAP implementations MUST support mutual peer authentication during
   tunnel establishment using the TLS ciphersuites specified in this
   section.  The TEAP peer does not need to authenticate as part of the
   TLS exchange but can alternatively be authenticated through
   additional exchanges carried out in Phase 2.

   The TEAP tunnel protects peer identity information exchanged during
   Phase 2 from disclosure outside the tunnel.  Implementations that
   wish to provide identity privacy for the peer identity need to
   carefully consider what information is disclosed outside the tunnel
   prior to Phase 2.  TEAP implementations SHOULD support the immediate
   renegotiation of a TLS session to initiate a new handshake message
   exchange under the protection of the current ciphersuite.  This
   allows support for protection of the peer's identity when using TLS
   client authentication.  An example of the exchanges using TLS
   renegotiation to protect privacy is shown in Appendix C.

   The following sections describe resuming a TLS session based on
   server-side or client-side state.

3.2.1.  TLS Session Resume Using Server State

   TEAP session resumption is achieved in the same manner TLS achieves
   session resume.  To support session resumption, the server and peer
   minimally cache the Session ID, master secret, and ciphersuite.  The
   peer attempts to resume a session by including a valid Session ID
   from a previous TLS handshake in its ClientHello message.  If the
   server finds a match for the Session ID and is willing to establish a
   new connection using the specified session state, the server will
   respond with the same Session ID and proceed with the TEAP Phase 1
   tunnel establishment based on a TLS abbreviated handshake.  After a
   successful conclusion of the TEAP Phase 1 conversation, the
   conversation then continues on to Phase 2.

Top      ToC       Page 12 
3.2.2.  TLS Session Resume Using a PAC

   TEAP supports the resumption of sessions based on server state being
   stored on the client side using the TLS SessionTicket extension
   techniques described in [RFC5077].  This version of TEAP supports the
   provisioning of a ticket called a Protected Access Credential (PAC)
   through the use of the NewSessionTicket handshake described in
   [RFC5077], as well as provisioning of a PAC inside the protected
   tunnel.  Implementations MUST support the TLS Ticket extension
   [RFC5077] mechanism for distributing a PAC and may provide additional
   ways to provision the PAC, such as manual configuration.  Since the
   PAC mentioned here is used for establishing the TLS tunnel, it is
   more specifically referred to as the Tunnel PAC.  The Tunnel PAC is a
   security credential provided by the EAP server to a peer and
   comprised of:

   1.  PAC-Key: this is the key used by the peer as the TLS master
       secret to establish the TEAP Phase 1 tunnel.  The PAC-Key is a
       strong, high-entropy, at minimum 48-octet key and is typically
       the master secret from a previous TLS session.  The PAC-Key is a
       secret and MUST be treated accordingly.  Otherwise, if leaked, it
       could lead to user credentials being compromised if sent within
       the tunnel established using the PAC-Key.  In the case that a
       PAC-Key is provisioned to the peer through another means, it MUST
       have its confidentiality and integrity protected by a mechanism,
       such as the TEAP Phase 2 tunnel.  The PAC-Key MUST be stored
       securely by the peer.

   2.  PAC-Opaque: this is a variable-length field containing the ticket
       that is sent to the EAP server during the TEAP Phase 1 tunnel
       establishment based on [RFC5077].  The PAC-Opaque can only be
       interpreted by the EAP server to recover the required information
       for the server to validate the peer's identity and
       authentication.  The PAC-Opaque includes the PAC-Key and other
       TLS session parameters.  It may contain the PAC's peer identity.
       The PAC-Opaque format and contents are specific to the PAC
       issuing server.  The PAC-Opaque may be presented in the clear, so
       an attacker MUST NOT be able to gain useful information from the
       PAC-Opaque itself.  The server issuing the PAC-Opaque needs to
       ensure it is protected with strong cryptographic keys and
       algorithms.  The PAC-Opaque may be distributed using the
       NewSessionTicket message defined in [RFC5077], or it may be
       distributed through another mechanism such as the Phase 2 TLVs
       defined in this document.

Top      ToC       Page 13 
   3.  PAC-Info: this is an optional variable-length field used to
       provide, at a minimum, the authority identity of the PAC issuer.
       Other useful but not mandatory information, such as the PAC-Key
       lifetime, may also be conveyed by the PAC-issuing server to the
       peer during PAC provisioning or refreshment.  PAC-Info is not
       included if the NewSessionTicket message is used to provision the
       PAC.

   The use of the PAC is based on the SessionTicket extension defined in
   [RFC5077].  The EAP server initiates the TEAP conversation as normal.
   Upon receiving the Authority-ID TLV from the server, the peer checks
   to see if it has an existing valid PAC-Key and PAC-Opaque for the
   server.  If it does, then it obtains the PAC-Opaque and puts it in
   the SessionTicket extension in the ClientHello.  It is RECOMMENDED in
   TEAP that the peer include an empty Session ID in a ClientHello
   containing a PAC-Opaque.  This version of TEAP supports the
   NewSessionTicket Handshake message as described in [RFC5077] for
   distribution of a new PAC, as well as the provisioning of PAC inside
   the protected tunnel.  If the PAC-Opaque included in the
   SessionTicket extension is valid and the EAP server permits the
   abbreviated TLS handshake, it will select the ciphersuite from
   information within the PAC-Opaque and finish with the abbreviated TLS
   handshake.  If the server receives a Session ID and a PAC-Opaque in
   the SessionTicket extension in a ClientHello, it should place the
   same Session ID in the ServerHello if it is resuming a session based
   on the PAC-Opaque.  The conversation then proceeds as described in
   [RFC5077] until the handshake completes or a fatal error occurs.
   After the abbreviated handshake completes, the peer and the server
   are ready to commence Phase 2.

3.2.3.  Transition between Abbreviated and Full TLS Handshake

   If session resumption based on server-side or client-side state
   fails, the server can gracefully fall back to a full TLS handshake.
   If the ServerHello received by the peer contains an empty Session ID
   or a Session ID that is different than in the ClientHello, the server
   may fall back to a full handshake.  The peer can distinguish the
   server's intent to negotiate a full or abbreviated TLS handshake by
   checking the next TLS handshake messages in the server response to
   the ClientHello.  If ChangeCipherSpec follows the ServerHello in
   response to the ClientHello, then the server has accepted the session
   resumption and intends to negotiate the abbreviated handshake.
   Otherwise, the server intends to negotiate the full TLS handshake.  A
   peer can request that a new PAC be provisioned after the full TLS
   handshake and mutual authentication of the peer and the server.  A
   peer SHOULD NOT request that a new PAC be provisioned after the
   abbreviated handshake, as requesting a new session ticket based on
   resumed session is not permitted.  In order to facilitate the

Top      ToC       Page 14 
   fallback to a full handshake, the peer SHOULD include ciphersuites
   that allow for a full handshake and possibly PAC provisioning so the
   server can select one of these in case session resumption fails.  An
   example of the transition is shown in Appendix C.

3.3.  TEAP Authentication Phase 2: Tunneled Authentication

   The second portion of the TEAP authentication occurs immediately
   after successful completion of Phase 1.  Phase 2 occurs even if both
   peer and authenticator are authenticated in the Phase 1 TLS
   negotiation.  Phase 2 MUST NOT occur if the Phase 1 TLS handshake
   fails, as that will compromise the security as the tunnel has not
   been established successfully.  Phase 2 consists of a series of
   requests and responses encapsulated in TLV objects defined in
   Section 4.2.  Phase 2 MUST always end with a Crypto-Binding TLV
   exchange described in Section 4.2.13 and a protected termination
   exchange described in Section 3.3.3.  The TLV exchange may include
   the execution of zero or more EAP methods within the protected tunnel
   as described in Section 3.3.1.  A server MAY proceed directly to the
   protected termination exchange if it does not wish to request further
   authentication from the peer.  However, the peer and server MUST NOT
   assume that either will skip inner EAP methods or other TLV
   exchanges, as the other peer might have a different security policy.
   The peer may have roamed to a network that requires conformance with
   a different authentication policy, or the peer may request the server
   take additional action (e.g., channel binding) through the use of the
   Request-Action TLV as defined in Section 4.2.9.

3.3.1.  EAP Sequences

   EAP [RFC3748] prohibits use of multiple authentication methods within
   a single EAP conversation in order to limit vulnerabilities to man-
   in-the-middle attacks.  TEAP addresses man-in-the-middle attacks
   through support for cryptographic protection of the inner EAP
   exchange and cryptographic binding of the inner authentication
   method(s) to the protected tunnel.  EAP methods are executed serially
   in a sequence.  This version of TEAP does not support initiating
   multiple EAP methods simultaneously in parallel.  The methods need
   not be distinct.  For example, EAP-TLS could be run twice as an inner
   method, first using machine credentials followed by a second instance
   using user credentials.

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.  The peer MUST respond
   to the Intermediate-Result TLV indicating its result.  If the result
   indicates success, the Intermediate-Result TLV MUST be accompanied by

Top      ToC       Page 15 
   a Crypto-Binding TLV.  The Crypto-Binding TLV is further discussed in
   Sections 4.2.13 and 5.3.  The Intermediate-Result TLVs can be
   included with other TLVs such as EAP-Payload TLVs starting a new EAP
   conversation or with the Result TLV used in the protected termination
   exchange.

   If both peer and server indicate success, then the method is
   considered complete.  If either indicates failure, then the method is
   considered failed.  The result of failure of an EAP method does not
   always imply a failure of the overall authentication.  If one
   authentication method fails, the server may attempt to authenticate
   the peer with a different method.

3.3.2.  Optional Password Authentication

   The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT
   RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with
   EAP-GTC defined in [RFC3748].  Implementations should instead make
   use of the password authentication TLVs defined in this
   specification.  The authentication server initiates password
   authentication by sending a Basic-Password-Auth-Req TLV defined in
   Section 4.2.14.  If the peer wishes to participate in password
   authentication, then it responds with a Basic-Password-Auth-Resp TLV
   as defined in Section 4.2.15 that contains the username and password.
   If it does not wish to perform password authentication, then it
   responds with a NAK TLV indicating the rejection of the Basic-
   Password-Auth-Req TLV.  Upon receiving the response, the server
   indicates the success or failure of the exchange using an
   Intermediate-Result TLV.  Multiple round trips of password
   authentication requests and responses MAY be used to support some
   "housecleaning" functions such as a password or pin change before a
   user is authenticated.

3.3.3.  Protected Termination and Acknowledged Result Indication

   A successful TEAP Phase 2 conversation MUST always end in a
   successful Crypto-Binding TLV and Result TLV exchange.  A TEAP server
   may initiate the Crypto-Binding TLV and Result TLV exchange without
   initiating any EAP conversation in TEAP Phase 2.  After the final
   Result TLV exchange, the TLS tunnel is terminated, and a cleartext
   EAP Success or EAP Failure is sent by the server.  Peers implementing
   TEAP MUST NOT accept a cleartext EAP Success or failure packet prior
   to the peer and server reaching synchronized protected result
   indication.

   The Crypto-Binding TLV exchange is used to prove that both the peer
   and server participated in the tunnel establishment and sequence of
   authentications.  It also provides verification of the TEAP type,

Top      ToC       Page 16 
   version negotiated, and Outer TLVs exchanged before the TLS tunnel
   establishment.  The Crypto-Binding TLV MUST be exchanged and verified
   before the final Result TLV exchange, regardless of whether or not
   there is an inner EAP method authentication.  The Crypto-Binding TLV
   and Intermediate-Result TLV MUST be included to perform cryptographic
   binding after each successful EAP method in a sequence of one or more
   EAP methods.  The server may send the final Result TLV along with an
   Intermediate-Result TLV and a Crypto-Binding TLV to indicate its
   intention to end the conversation.  If the peer requires nothing more
   from the server, it will respond with a Result TLV indicating success
   accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if
   necessary.  The server then tears down the tunnel and sends a
   cleartext EAP Success or EAP Failure.

   If the peer receives a Result TLV indicating success from the server,
   but its authentication policies are not satisfied (for example, it
   requires a particular authentication mechanism be run or it wants to
   request a PAC), it may request further action from the server using
   the Request-Action TLV.  The Request-Action TLV is sent with a Status
   field indicating what EAP Success/Failure result the peer would
   expect if the requested action is not granted.  The value of the
   Action field indicates what the peer would like to do next.  The
   format and values for the Request-Action TLV are defined in
   Section 4.2.9.

   Upon receiving the Request-Action TLV, the server may process the
   request or ignore it, based on its policy.  If the server ignores the
   request, it proceeds with termination of the tunnel and sends the
   cleartext EAP Success or Failure message based on the Status field of
   the peer's Request-Action TLV.  If the server honors and processes
   the request, it continues with the requested action.  The
   conversation completes with a Result TLV exchange.  The Result TLV
   may be included with the TLV that completes the requested action.

   Error handling for Phase 2 is discussed in Section 3.6.3.

3.4.  Determining Peer-Id and Server-Id

   The Peer-Id and Server-Id [RFC5247] may be determined based on the
   types of credentials used during either the TEAP tunnel creation or
   authentication.  In the case of multiple peer authentications, all
   authenticated peer identities and their corresponding identity types
   (Section 4.2.3) need to be exported.  In the case of multiple server
   authentications, all authenticated server identities need to be
   exported.

Top      ToC       Page 17 
   When X.509 certificates are used for peer authentication, the Peer-Id
   is determined by the subject and subjectAltName fields in the peer
   certificate.  As noted in [RFC5280]:

     The subject field identifies the entity associated with the public
     key stored in the subject public key field.  The subject name MAY
     be carried in the subject field and/or the subjectAltName
     extension. . . . If subject naming information is present only in
     the subjectAltName extension (e.g., a key bound only to an email
     address or URI), then the subject name MUST be an empty sequence
     and the subjectAltName extension MUST be critical.

     Where it is non-empty, the subject field MUST contain an X.500
     distinguished name (DN).

   If an inner EAP method is run, then the Peer-Id is obtained from the
   inner method.

   When the server uses an X.509 certificate to establish the TLS
   tunnel, the Server-Id is determined in a similar fashion as stated
   above for the Peer-Id, e.g., the subject and subjectAltName fields in
   the server certificate define the Server-Id.

3.5.  TEAP Session Identifier

   The EAP session identifier [RFC5247] is constructed using the tls-
   unique from the Phase 1 outer tunnel at the beginning of Phase 2 as
   defined by Section 3.1 of [RFC5929].  The Session-Id is defined as
   follows:

     Session-Id = teap_type || tls-unique

     where teap_type is the EAP Type assigned to TEAP

     tls-unique = tls-unique from the Phase 1 outer tunnel at the
     beginning of Phase 2 as defined by Section 3.1 of [RFC5929]

     || means concatenation

3.6.  Error Handling

   TEAP uses the error-handling rules summarized below:

   1.  Errors in the outer EAP packet layer are handled as defined in
       Section 3.6.1.

   2.  Errors in the TLS layer are communicated via TLS alert messages
       in all phases of TEAP.

Top      ToC       Page 18 
   3.  The Intermediate-Result TLVs carry success or failure indications
       of the individual EAP methods in TEAP Phase 2.  Errors within the
       EAP conversation in Phase 2 are expected to be handled by
       individual EAP methods.

   4.  Violations of the Inner TLV rules are handled using Result TLVs
       together with Error TLVs.

   5.  Tunnel-compromised errors (errors caused by a failed or missing
       Crypto-Binding) are handled using Result TLVs and Error TLVs.

3.6.1.  Outer-Layer Errors

   Errors on the TEAP outer-packet layer are handled in the following
   ways:

   1.  If Outer TLVs are invalid or contain unknown values, they will be
       ignored.

   2.  The entire TEAP packet will be ignored if other fields (version,
       length, flags, etc.) are inconsistent with this specification.

3.6.2.  TLS Layer Errors

   If the TEAP server detects an error at any point in the TLS handshake
   or the TLS layer, the server SHOULD send a TEAP request encapsulating
   a TLS record containing the appropriate TLS alert message rather than
   immediately terminating the conversation so as to allow the peer to
   inform the user of the cause of the failure and possibly allow for a
   restart of the conversation.  The peer MUST send a TEAP response to
   an alert message.  The EAP-Response packet sent by the peer may
   encapsulate a TLS ClientHello handshake message, in which case the
   TEAP server MAY allow the TEAP conversation to be restarted, or it
   MAY contain a TEAP response with a zero-length message, in which case
   the server MUST terminate the conversation with an EAP Failure
   packet.  It is up to the TEAP server whether or not to allow
   restarts, and, if allowed, how many times the conversation can be
   restarted.  Per TLS [RFC5246], TLS restart is only allowed for non-
   fatal alerts.  A TEAP server implementing restart capability SHOULD
   impose a limit on the number of restarts, so as to protect against
   denial-of-service attacks.  If the TEAP server does not allow
   restarts, it MUST terminate the conversation with an EAP Failure
   packet.

   If the TEAP peer detects an error at any point in the TLS layer, the
   TEAP peer SHOULD send a TEAP response encapsulating a TLS record
   containing the appropriate TLS alert message.  The server may restart
   the conversation by sending a TEAP request packet encapsulating the

Top      ToC       Page 19 
   TLS HelloRequest handshake message.  The peer may allow the TEAP
   conversation to be restarted, or it may terminate the conversation by
   sending a TEAP response with a zero-length message.

3.6.3.  Phase 2 Errors

   Any time the peer or the server finds a fatal error outside of the
   TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of
   failure and an Error TLV with the appropriate error code.  For errors
   involving the processing of the sequence of exchanges, such as a
   violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error
   code is Unexpected TLVs Exchanged.  For errors involving a tunnel
   compromise, the error code is Tunnel Compromise Error.  Upon sending
   a Result TLV with a fatal Error TLV, the sender terminates the TLS
   tunnel.  Note that a server will still wait for a message from the
   peer after it sends a failure; however, the server does not need to
   process the contents of the response message.

   For the inner method, retransmission is not needed and SHOULD NOT be
   attempted, as the Outer TLS tunnel can be considered a reliable
   transport.  If there is a non-fatal error handling the inner method,
   instead of silently dropping the inner method request or response and
   not responding, the receiving side SHOULD use an Error TLV with error
   code Inner Method Error to indicate an error processing the current
   inner method.  The side receiving the Error TLV MAY decide to start a
   new inner method instead or send back a Result TLV to terminate the
   TEAP authentication session.

   If a server receives a Result TLV of failure with a fatal Error TLV,
   it MUST send a cleartext EAP Failure.  If a peer receives a Result
   TLV of failure, it MUST respond with a Result TLV indicating failure.
   If the server has sent a Result TLV of failure, it ignores the peer
   response, and it MUST send a cleartext EAP Failure.

3.7.  Fragmentation

   A single TLS record may be up to 16384 octets in length, but a TLS
   message may span multiple TLS records, and a TLS certificate message
   may, in principle, be as long as 16 MB.  This is larger than the
   maximum size for a message on most media types; therefore, it is
   desirable to support fragmentation.  Note that in order to protect
   against reassembly lockup and denial-of-service attacks, it may be
   desirable for an implementation to set a maximum size for one such
   group of TLS messages.  Since a typical certificate chain is rarely
   longer than a few thousand octets, and no other field is likely to be
   anywhere near as long, a reasonable choice of maximum acceptable
   message length might be 64 KB.  This is still a fairly large message
   packet size so a TEAP implementation MUST provide its own support for

Top      ToC       Page 20 
   fragmentation and reassembly.  Section 3.1 of [RFC3748] discusses
   determining the MTU usable by EAP, and Section 4.3 discusses
   retransmissions in EAP.

   Since EAP is a lock-step protocol, fragmentation support can be added
   in a simple manner.  In EAP, fragments that are lost or damaged in
   transit will be retransmitted, and since sequencing information is
   provided by the Identifier field in EAP, there is no need for a
   fragment offset field.

   TEAP fragmentation support is provided through the addition of flag
   bits within the EAP-Response and EAP-Request packets, as well as a
   Message Length field of four octets.  Flags include the Length
   included (L), More fragments (M), and TEAP Start (S) bits.  The L
   flag is set to indicate the presence of the four-octet Message Length
   field and MUST be set for the first fragment of a fragmented TLS
   message or set of messages.  It MUST NOT be present for any other
   message.  The M flag is set on all but the last fragment.  The S flag
   is set only within the TEAP start message sent from the EAP server to
   the peer.  The Message Length field is four octets and provides the
   total length of the message that may be fragmented over the data
   fields of multiple packets; this simplifies buffer allocation.

   When a TEAP peer receives an EAP-Request packet with the M bit set,
   it MUST respond with an EAP-Response with EAP Type of TEAP and no
   data.  This serves as a fragment ACK.  The EAP server MUST wait until
   it receives the EAP-Response before sending another fragment.  In
   order to prevent errors in processing of fragments, the EAP server
   MUST increment the Identifier field for each fragment contained
   within an EAP-Request, and the peer MUST include this Identifier
   value in the fragment ACK contained within the EAP-Response.
   Retransmitted fragments will contain the same Identifier value.

   Similarly, when the TEAP server receives an EAP-Response with the M
   bit set, it responds with an EAP-Request with EAP Type of TEAP and no
   data.  This serves as a fragment ACK.  The EAP peer MUST wait until
   it receives the EAP-Request before sending another fragment.  In
   order to prevent errors in the processing of fragments, the EAP
   server MUST increment the Identifier value for each fragment ACK
   contained within an EAP-Request, and the peer MUST include this
   Identifier value in the subsequent fragment contained within an EAP-
   Response.

3.8.  Peer Services

   Several TEAP services, including server unauthenticated provisioning,
   PAC provisioning, certificate provisioning, and channel binding,
   depend on the peer trusting the TEAP server.  Peers MUST authenticate

Top      ToC       Page 21 
   the server before these peer services are used.  TEAP peer
   implementations MUST have a configuration where authentication fails
   if server authentication cannot be achieved.  In many cases, the
   server will want to authenticate the peer before providing these
   services as well.

   TEAP peers MUST track whether or not server authentication has taken
   place.  Server authentication results if the peer trusts the provided
   server certificate.  Typically, this involves both validating the
   certificate to a trust anchor and confirming the entity named by the
   certificate is the intended server.  Server authentication also
   results when the procedures in Section 3.2 are used to resume a
   session in which the peer and server were previously mutually
   authenticated.  Alternatively, peer services can be used if an inner
   EAP method providing mutual authentication and an Extended Master
   Session Key (EMSK) is executed and cryptographic binding with the
   EMSK Compound Message Authentication Code (MAC) is correctly
   validated (Section 4.2.13).  This is further described in
   Section 3.8.3.

   An additional complication arises when a tunnel method authenticates
   multiple parties such as authenticating both the peer machine and the
   peer user to the EAP server.  Depending on how authentication is
   achieved, only some of these parties may have confidence in it.  For
   example, if a strong shared secret is used to mutually authenticate
   the user and the EAP server, the machine may not have confidence that
   the EAP server is the authenticated party if the machine cannot trust
   the user not to disclose the shared secret to an attacker.  In these
   cases, the parties who participate in the authentication need to be
   considered when evaluating whether to use peer services.

3.8.1.  PAC Provisioning

   To request provisioning of a PAC, a peer sends a PAC TLV as defined
   in Section 4.2.12 containing a PAC Attribute as defined in
   Section 4.2.12.1 of PAC-Type set to the appropriate value.  The peer
   MUST successfully authenticate the EAP server and validate the
   Crypto-Binding TLV as defined in Section 4.2.13 before issuing the
   request.  The peer MUST send separate PAC TLVs for each type of PAC
   it wants to be provisioned.  Multiple PAC TLVs can be sent in the
   same packet or in different packets.  The EAP server will send the
   PACs after its internal policy has been satisfied, or it MAY ignore
   the request or request additional authentications if its policy
   dictates.  The server MAY cache the request and provision the PACs
   requested after all of its internal policies have been satisfied.  If
   a peer receives a PAC with an unknown type, it MUST ignore it.

Top      ToC       Page 22 
   A PAC TLV containing a PAC-Acknowledge attribute MUST be sent by the
   peer to acknowledge the receipt of the Tunnel PAC.  A PAC TLV
   containing a PAC-Acknowledge attribute MUST NOT be used by the peer
   to acknowledge the receipt of other types of PACs.  If the peer
   receives a PAC TLV with an unknown attribute, it SHOULD ignore the
   unknown attribute.

3.8.2.  Certificate Provisioning within the Tunnel

   Provisioning of a peer's certificate is supported in TEAP by
   performing the Simple PKI Request/Response from [RFC5272] using
   PKCS#10 and PKCS#7 TLVs, respectively.  A peer sends the Simple PKI
   Request using a PKCS#10 CertificateRequest [RFC2986] encoded into the
   body of a PKCS#10 TLV (see Section 4.2.17).  The TEAP server issues a
   Simple PKI Response using a PKCS#7 [RFC2315] degenerate "Certificates
   Only" message encoded into the body of a PKCS#7 TLV (see
   Section 4.2.16), only after an authentication method has run and
   provided an identity proof on the peer prior to a certificate is
   being issued.

   In order to provide linking identity and proof-of-possession by
   including information specific to the current authenticated TLS
   session within the signed certification request, the peer generating
   the request SHOULD obtain the tls-unique value from the TLS subsystem
   as defined in "Channel Bindings for TLS" [RFC5929].  The TEAP peer
   operations between obtaining the tls_unique value through generation
   of the Certification Signing Request (CSR) that contains the current
   tls_unique value and the subsequent verification of this value by the
   TEAP server are the "phases of the application protocol during which
   application-layer authentication occurs" that are protected by the
   synchronization interoperability mechanism described in the
   interoperability note in "Channel Bindings for TLS" ([RFC5929],
   Section 3.1).  When performing renegotiation, TLS
   "secure_renegotiation" [RFC5746] MUST be used.

   The tls-unique value is base-64-encoded as specified in Section 4 of
   [RFC4648], and the resulting string is placed in the certification
   request challengePassword field ([RFC2985], Section 5.4.1).  The
   challengePassword field is limited to 255 octets (Section 7.4.9 of
   [RFC5246] indicates that no existing ciphersuite would result in an
   issue with this limitation).  If tls-unique information is not
   embedded within the certification request, the challengePassword
   field MUST be empty to indicate that the peer did not include the
   optional channel-binding information (any value submitted is verified
   by the server as tls-unique information).

Top      ToC       Page 23 
   The server SHOULD verify the tls-unique information.  This ensures
   that the authenticated TEAP peer is in possession of the private key
   used to sign the certification request.

   The Simple PKI Request/Response generation and processing rules of
   [RFC5272] SHALL apply to TEAP, with the exception of error
   conditions.  In the event of an error, the TEAP server SHOULD respond
   with an Error TLV using the most descriptive error code possible; it
   MAY ignore the PKCS#10 request that generated the error.

3.8.3.  Server Unauthenticated Provisioning Mode

   In Server Unauthenticated Provisioning Mode, an unauthenticated
   tunnel is established in Phase 1, and the peer and server negotiate
   an EAP method in Phase 2 that supports mutual authentication and key
   derivation that is resistant to attacks such as man-in-the-middle and
   dictionary attacks.  This provisioning mode enables the bootstrapping
   of peers when the peer lacks the ability to authenticate the server
   during Phase 1.  This includes both cases in which the ciphersuite
   negotiated does not provide authentication and in which the
   ciphersuite negotiated provides the authentication but the peer is
   unable to validate the identity of the server for some reason.

   Upon successful completion of the EAP method in Phase 2, the peer and
   server exchange a Crypto-Binding TLV to bind the inner method with
   the outer tunnel and ensure that a man-in-the-middle attack has not
   been attempted.

   Support for the Server Unauthenticated Provisioning Mode is optional.
   The ciphersuite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when
   using Server Unauthenticated Provisioning Mode, but other anonymous
   ciphersuites MAY be supported as long as the TLS pre-master secret is
   generated from contribution from both peers.  Phase 2 EAP methods
   used in Server Unauthenticated Provisioning Mode MUST provide mutual
   authentication, provide key generation, and be resistant to
   dictionary attack.  Example inner methods include EAP-pwd [RFC5931]
   and EAP-EKE [RFC6124].

3.8.4.  Channel Binding

   [RFC6677] defines EAP channel bindings to solve the "lying NAS" and
   the "lying provider" problems, using a process in which the EAP peer
   gives information about the characteristics of the service provided
   by the authenticator to the Authentication, Authorization, and
   Accounting (AAA) server protected within the EAP method.  This allows
   the server to verify the authenticator is providing information to

Top      ToC       Page 24 
   the peer that is consistent with the information received from this
   authenticator as well as the information stored about this
   authenticator.

   TEAP supports EAP channel binding using the Channel-Binding TLV
   defined in Section 4.2.7.  If the TEAP server wants to request the
   channel-binding information from the peer, it sends an empty Channel-
   Binding TLV to indicate the request.  The peer responds to the
   request by sending a Channel-Binding TLV containing a channel-binding
   message as defined in [RFC6677].  The server validates the channel-
   binding message and sends back a Channel-Binding TLV with a result
   code.  If the server didn't initiate the channel-binding request and
   the peer still wants to send the channel-binding information to the
   server, it can do that by using the Request-Action TLV along with the
   Channel-Binding TLV.  The peer MUST only send channel-binding
   information after it has successfully authenticated the server and
   established the protected tunnel.



(page 24 continued on part 2)

Next RFC Part