RFC 7170
Tunnel Extensible Authentication Protocol (TEAP) Version 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 1Abstract
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.
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
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
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
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].
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
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.
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.
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.
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
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.
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.
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
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
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,
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.
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 concatenation3.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.
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
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
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
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.
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).
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
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)
