idnits 2.17.1 draft-ietf-emu-eap-tunnel-method-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 9, 2014) is 3760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NOTE1' is mentioned on line 2678, but not defined -- Looks like a reference, but probably isn't: '0' on line 2788 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group H. Zhou 3 Internet-Draft N. Cam-Winget 4 Intended status: Standards Track J. Salowey 5 Expires: July 13, 2014 Cisco Systems 6 S. Hanna 7 Juniper Networks 8 January 9, 2014 10 Tunnel EAP Method (TEAP) Version 1 11 draft-ietf-emu-eap-tunnel-method-10.txt 13 Abstract 15 This document defines the Tunnel Extensible Authentication Protocol 16 (TEAP) version 1. TEAP is a tunnel based EAP method that enables 17 secure communication between a peer and a server by using the 18 Transport Layer Security (TLS) protocol to establish a mutually 19 authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) 20 objects are used to convey authentication related data between the 21 EAP peer and the EAP server. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 13, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.1. Specification Requirements . . . . . . . . . . . . . . . 5 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 7 62 2.2. Protocol Layering Model . . . . . . . . . . . . . . . . . 7 63 3. TEAP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 9 65 3.2. TEAP Authentication Phase 1: Tunnel Establishment . . . . 10 66 3.2.1. TLS Session Resume Using Server State . . . . . . . . 11 67 3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . 12 68 3.2.3. Transition between Abbreviated and Full TLS Handshake 13 69 3.3. TEAP Authentication Phase 2: Tunneled Authentication . . 14 70 3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 14 71 3.3.2. Optional Password Authentication . . . . . . . . . . 15 72 3.3.3. Protected Termination and Acknowledged Result 73 Indication . . . . . . . . . . . . . . . . . . . . . 15 74 3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 16 75 3.5. TEAP Session Identifier . . . . . . . . . . . . . . . . . 17 76 3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 17 77 3.6.1. Outer Layer Errors . . . . . . . . . . . . . . . . . 18 78 3.6.2. TLS Layer Errors . . . . . . . . . . . . . . . . . . 18 79 3.6.3. Phase 2 Errors . . . . . . . . . . . . . . . . . . . 19 80 3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 19 81 3.8. Peer Services . . . . . . . . . . . . . . . . . . . . . . 20 82 3.8.1. PAC Provisioning . . . . . . . . . . . . . . . . . . 21 83 3.8.2. Certificate Provisioning Within the Tunnel . . . . . 22 84 3.8.3. Server Unauthenticated Provisioning Mode . . . . . . 23 85 3.8.4. Channel Binding . . . . . . . . . . . . . . . . . . . 23 86 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 24 87 4.1. TEAP Message Format . . . . . . . . . . . . . . . . . . . 24 88 4.2. TEAP TLV Format and Support . . . . . . . . . . . . . . . 26 89 4.2.1. General TLV Format . . . . . . . . . . . . . . . . . 27 90 4.2.2. Authority-ID TLV . . . . . . . . . . . . . . . . . . 29 91 4.2.3. Identity-Type TLV . . . . . . . . . . . . . . . . . . 30 92 4.2.4. Result TLV . . . . . . . . . . . . . . . . . . . . . 31 93 4.2.5. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 32 94 4.2.6. Error TLV . . . . . . . . . . . . . . . . . . . . . . 34 95 4.2.7. Channel-Binding TLV . . . . . . . . . . . . . . . . . 37 96 4.2.8. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 38 97 4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . 39 98 4.2.10. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 41 99 4.2.11. Intermediate-Result TLV . . . . . . . . . . . . . . . 42 100 4.2.12. PAC TLV Format . . . . . . . . . . . . . . . . . . . 44 101 4.2.12.1. Formats for PAC Attributes . . . . . . . . . . . 44 102 4.2.12.2. PAC-Key . . . . . . . . . . . . . . . . . . . . 45 103 4.2.12.3. PAC-Opaque . . . . . . . . . . . . . . . . . . . 46 104 4.2.12.4. PAC-Info . . . . . . . . . . . . . . . . . . . . 47 105 4.2.12.5. PAC-Acknowledgement TLV . . . . . . . . . . . . 49 106 4.2.12.6. PAC-Type TLV . . . . . . . . . . . . . . . . . . 50 107 4.2.13. Crypto-Binding TLV . . . . . . . . . . . . . . . . . 50 108 4.2.14. Basic-Password-Auth-Req TLV . . . . . . . . . . . . . 53 109 4.2.15. Basic-Password-Auth-Resp TLV . . . . . . . . . . . . 54 110 4.2.16. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . 56 111 4.2.17. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 57 112 4.2.18. Trusted-Server-Root TLV . . . . . . . . . . . . . . . 58 113 4.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 59 114 4.3.1. Outer TLVs . . . . . . . . . . . . . . . . . . . . . 60 115 4.3.2. Inner TLVs . . . . . . . . . . . . . . . . . . . . . 60 116 5. Cryptographic Calculations . . . . . . . . . . . . . . . . . 61 117 5.1. TEAP Authentication Phase 1: Key Derivations . . . . . . 61 118 5.2. Intermediate Compound Key Derivations . . . . . . . . . . 62 119 5.3. Computing the Compound MAC . . . . . . . . . . . . . . . 64 120 5.4. EAP Master Session Key Generation . . . . . . . . . . . . 64 121 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 122 7. Security Considerations . . . . . . . . . . . . . . . . . . . 69 123 7.1. Mutual Authentication and Integrity Protection . . . . . 70 124 7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . 70 125 7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 71 126 7.4. Mitigation of Known Vulnerabilities and Protocol 127 Deficiencies . . . . . . . . . . . . . . . . . . . . . . 71 128 7.4.1. User Identity Protection and Verification . . . . . . 72 129 7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . 73 130 7.4.3. Protection against Man-in-the-Middle Attacks . . . . 73 131 7.4.4. PAC Binding to User Identity . . . . . . . . . . . . 74 132 7.5. Protecting against Forged Clear Text EAP Packets . . . . 74 133 7.6. Server Certificate Validation . . . . . . . . . . . . . . 75 134 7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 75 135 7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 76 136 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 137 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 138 9.1. Normative References . . . . . . . . . . . . . . . . . . 77 139 9.2. Informative References . . . . . . . . . . . . . . . . . 78 140 Appendix A. Evaluation Against Tunnel Based EAP Method 141 Requirements . . . . . . . . . . . . . . . . . . . . 81 142 A.1. Requirement 4.1.1 RFC Compliance . . . . . . . . . . . . 81 143 A.2. Requirement 4.2.1 TLS Requirements . . . . . . . . . . . 81 144 A.3. Requirement 4.2.1.1.1 Cipher Suite Negotiation . . . . . 81 145 A.4. Requirement 4.2.1.1.2 Tunnel Data Protection Algorithms . 81 146 A.5. Requirement 4.2.1.1.3 Tunnel Authentication and Key 147 Establishment . . . . . . . . . . . . . . . . . . . . . . 82 148 A.6. Requirement 4.2.1.2 Tunnel Replay Protection . . . . . . 82 149 A.7. Requirement 4.2.1.3 TLS Extensions . . . . . . . . . . . 82 150 A.8. Requirement 4.2.1.4 Peer Identity Privacy . . . . . . . . 82 151 A.9. Requirement 4.2.1.5 Session Resumption . . . . . . . . . 82 152 A.10. Requirement 4.2.2 Fragmentation . . . . . . . . . . . . . 82 153 A.11. Requirement 4.2.3 Protection of Data External to Tunnel . 82 154 A.12. Requirement 4.3.1 Extensible Attribute Types . . . . . . 83 155 A.13. Requirement 4.3.2 Request/Challenge Response Operation . 83 156 A.14. Requirement 4.3.3 Indicating Criticality of Attributes . 83 157 A.15. Requirement 4.3.4 Vendor Specific Support . . . . . . . . 83 158 A.16. Requirement 4.3.5 Result Indication . . . . . . . . . . . 83 159 A.17. Requirement 4.3.6 Internationalization of Display Strings 83 160 A.18. Requirement 4.4 EAP Channel Binding Requirements . . . . 83 161 A.19. Requirement 4.5.1.1 Confidentiality and Integrity . . . . 83 162 A.20. Requirement 4.5.1.2 Authentication of Server . . . . . . 84 163 A.21. Requirement 4.5.1.3 Server Certificate Revocation 164 Checking . . . . . . . . . . . . . . . . . . . . . . . . 84 165 A.22. Requirement 4.5.2 Internationalization . . . . . . . . . 84 166 A.23. Requirement 4.5.3 Meta-data . . . . . . . . . . . . . . . 84 167 A.24. Requirement 4.5.4 Password Change . . . . . . . . . . . . 84 168 A.25. Requirement 4.6.1 Method Negotiation . . . . . . . . . . 84 169 A.26. Requirement 4.6.2 Chained Methods . . . . . . . . . . . . 84 170 A.27. Requirement 4.6.3 Cryptographic Binding with the TLS 171 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 84 172 A.28. Requirement 4.6.4 Peer Initiated . . . . . . . . . . . . 85 173 A.29. Requirement 4.6.5 Method Meta-data . . . . . . . . . . . 85 174 Appendix B. Major Differences from EAP-FAST . . . . . . . . . . 85 175 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 85 176 C.1. Successful Authentication . . . . . . . . . . . . . . . . 86 177 C.2. Failed Authentication . . . . . . . . . . . . . . . . . . 87 178 C.3. Full TLS Handshake using Certificate-based Cipher Suite . 89 179 C.4. Client authentication during Phase 1 with identity 180 privacy . . . . . . . . . . . . . . . . . . . . . . . . . 90 181 C.5. Fragmentation and Reassembly . . . . . . . . . . . . . . 92 182 C.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 94 183 C.7. Failed Crypto-binding . . . . . . . . . . . . . . . . . . 96 184 C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange 97 185 C.9. Peer Requests Inner Method After Server Sends Result TLV 99 186 C.10. Channel Binding . . . . . . . . . . . . . . . . . . . . . 101 187 Appendix D. Major Differences from Previous Revisions . . . . . 102 188 D.1. Changes from -06 . . . . . . . . . . . . . . . . . . . . 102 189 D.2. Changes from -05 . . . . . . . . . . . . . . . . . . . . 103 190 D.3. Changes from -04 . . . . . . . . . . . . . . . . . . . . 103 191 D.4. Changes from -03 . . . . . . . . . . . . . . . . . . . . 104 192 D.5. Changes from -02 . . . . . . . . . . . . . . . . . . . . 104 193 D.6. Changes from -01 . . . . . . . . . . . . . . . . . . . . 105 194 D.7. Changes from -00 . . . . . . . . . . . . . . . . . . . . 105 196 1. Introduction 198 An Extensible Authentication Protocol (EAP) tunnel method is an EAP 199 method that establishes a secure tunnel and executes other EAP 200 methods under the protection of that secure tunnel. An EAP tunnel 201 method can be used in any lower layer protocol that supports EAP 202 authentication. There are several existing EAP tunnel methods that 203 use Transport Layer Security (TLS) [RFC5246] to establish the secure 204 tunnel. EAP methods supporting this include Protected EAP (PEAP) 205 [PEAP], Tunneled Transport Layer Security EAP (TTLS) [RFC5281] and 206 EAP Flexible Authentication via Secure Tunneling (EAP-FAST) 207 [RFC4851]. However, they all are either vendor specific or 208 informational and industry calls for a standard-track tunnel EAP 209 method. [RFC6678] outlines the list of requirements for a standard 210 tunnel based EAP method. 212 Since the introduction of EAP-FAST [RFC4851] a few years ago, it has 213 been widely adopted in variety of devices and platforms. It has been 214 adopted by EMU working group as the basis for the standard tunnel 215 based EAP method. This document describes Tunnel Extensible 216 Authentication Protocol (TEAP) version 1, based on EAP-FAST [RFC4851] 217 with some minor changes, to meet the requirements outlined in 218 [RFC6678] for a standard tunnel based EAP method. 220 1.1. Specification Requirements 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 224 "OPTIONAL" in this document are to be interpreted as described in 225 [RFC2119] . 227 1.2. Terminology 229 Much of the terminology in this document comes from [RFC3748]. 230 Additional terms are defined below: 232 Protected Access Credential (PAC) 234 Credentials distributed to a peer for future optimized network 235 authentication. The PAC consists of a minimum of two components: 236 a shared secret and an opaque element. The shared secret 237 component contains the pre-shared key between the peer and the 238 authentication server. The opaque part is provided to the peer 239 and is presented to the authentication server when the peer wishes 240 to obtain access to network resources. The opaque element and 241 shared secret are used with TLS stateless session resumption 242 defined in [RFC5077] to establish a protected TLS session. The 243 secret key and opaque part may be distributed using RFC 5077 244 messages or using TLVs within the TEAP tunnel. Finally, a PAC may 245 optionally include other information that may be useful to the 246 peer. 248 Type-Length-Value (TLV) 250 The TEAP protocol utilizes objects in Type-Length-Value (TLV) 251 format. The TLV format is defined in Section 4.2. 253 2. Protocol Overview 255 TEAP authentication occurs in two phases after the initial EAP 256 Identity request/response exchange. In the first phase, TEAP employs 257 the TLS [RFC5246] handshake to provide an authenticated key exchange 258 and to establish a protected tunnel. Once the tunnel is established, 259 the second phase begins with the peer and server engaging in further 260 conversations to establish the required authentication and 261 authorization policies. TEAP makes use of Type-Length-Value objects 262 (TLVs) to carry out the inner authentication, results and other 263 information, such as channel binding information. 265 TEAP makes use of the TLS SessionTicket Extension [RFC5077] which 266 supports TLS session resumption without requiring session-specific 267 state stored at the server. In this document, the SessionTicket is 268 referred to as the Protected Access Credential opaque data (or PAC- 269 Opaque). The PAC-Opaque may be distributed through the use of the 270 NewSessionTicket message or through a mechanism that uses TLVs within 271 phase 2 of TEAP. The secret key used to resume the session in TEAP 272 is referred to as the Protected Access Credential key (or PAC-Key). 273 When the NewSessionTicket message is used to distribute the PAC- 274 Opaque, the PAC-Key is the Master Secret for the session. If TEAP 275 phase 2 is used to distribute the PAC-Opaque, then the PAC-Key is 276 distributed along with the PAC-Opaque. TEAP implementations MUST 277 support the RFC 5077 mechanism for distributing a PAC-Opaque and it 278 is RECOMMENDED that implementations support the capability to 279 distribute the ticket and secret key within the TEAP tunnel. 281 The TEAP conversation is used to establish or resume an existing 282 session to typically establish network connectivity between a peer 283 and the network. Upon successful execution of TEAP, both EAP peer 284 and EAP server derive strong session key material that can then be 285 communicated to the network access server (NAS) for use in 286 establishing a link layer security association. 288 2.1. Architectural Model 290 The network architectural model for TEAP usage is shown below: 292 +----------+ +----------+ +----------+ +----------+ 293 | | | | | | | Inner | 294 | Peer |<---->| Authen- |<---->| TEAP |<---->| Method | 295 | | | ticator | | server | | server | 296 | | | | | | | | 297 +----------+ +----------+ +----------+ +----------+ 299 TEAP Architectural Model 301 The entities depicted above are logical entities and may or may not 302 correspond to separate network components. For example, the TEAP 303 server and inner method server might be a single entity; or the 304 authenticator and TEAP server might be a single entity; or the 305 functions of the authenticator, TEAP server, and inner method server 306 might be combined into a single physical device. For example, 307 typical IEEE 802.11 deployments place the Authenticator in an access 308 point (AP) while a Radius server may provide the TEAP and inner 309 method server components. The above diagram illustrates the division 310 of labor among entities in a general manner and shows how a 311 distributed system might be constructed; however, actual systems 312 might be realized more simply. The security considerations 313 Section 7.3 provides an additional discussion of the implications of 314 separating the TEAP server from the inner method server. 316 2.2. Protocol Layering Model 318 TEAP packets are encapsulated within EAP; EAP in turn requires a 319 transport protocol. TEAP packets encapsulate TLS, which is then used 320 to encapsulate user authentication information. Thus, TEAP messaging 321 can be described using a layered model, where each layer encapsulates 322 the layer above it. The following diagram clarifies the relationship 323 between protocols: 325 +---------------------------------------------------------------+ 326 | Inner EAP Method | Other TLV information | 327 |---------------------------------------------------------------| 328 | TLV Encapsulation (TLVs) | 329 |---------------------------------------------------------------| 330 | TLS | Optional Outer TLVs | 331 |---------------------------------------------------------------| 332 | TEAP | 333 |---------------------------------------------------------------| 334 | EAP | 335 |---------------------------------------------------------------| 336 | Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) | 337 +---------------------------------------------------------------+ 339 Protocol Layering Model 341 The TLV layer is a payload with Type-Length-Value (TLV) Objects 342 defined in Section 4.2. The TLV objects are used to carry arbitrary 343 parameters between an EAP peer and an EAP server. All conversations 344 in the TEAP protected tunnel are encapsulated in a TLV layer. 346 TEAP packets may include TLVs both inside and outside the TLS tunnel. 347 The term "Outer TLVs" is used to refer to optional TLVs outside the 348 TLS tunnel, which are only allowed in the first two messages in the 349 TEAP protocol. That is the first EAP server to peer message and 350 first peer to EAP server message. If the message is fragmented, the 351 whole set of messages is counted as one message. The term "Inner 352 TLVs" is used to refer to TLVs sent within the TLS tunnel. In TEAP 353 Phase 1, Outer TLVs are used to help establishing the TLS tunnel, but 354 no Inner TLVs are used. In Phase 2 of the TEAP conversation, TLS 355 records may encapsulate zero or more Inner TLVs, but no Outer TLVs. 357 Methods for encapsulating EAP within carrier protocols are already 358 defined. For example, IEEE 802.1X [IEEE.802-1X.2004] may be used to 359 transport EAP between the peer and the authenticator; RADIUS 360 [RFC3579] or Diameter [RFC4072] may be used to transport EAP between 361 the authenticator and the EAP server. 363 3. TEAP Protocol 365 The operation of the protocol, including Phase 1 and Phase 2, is the 366 topic of this section. The format of TEAP messages is given in 367 Section 4 and the cryptographic calculations are given in Section 5. 369 3.1. Version Negotiation 371 TEAP packets contain a 3-bit version field, following the TLS Flags 372 field, which enables future TEAP implementations to be backward 373 compatible with previous versions of the protocol. This 374 specification documents the TEAP version 1 protocol; implementations 375 of this specification MUST use a version field set to 1. 377 Version negotiation proceeds as follows: 379 1. In the first EAP-Request sent with EAP type=TEAP, the EAP 380 server MUST set the version field to the highest version it 381 supports. 383 2a. If the EAP peer supports this version of the protocol, it 384 responds with an EAP-Response of EAP type=TEAP, including the 385 version number proposed by the TEAP server. 387 2b. If the TEAP peer does not support the proposed version but 388 supports a lower version, it responds with an EAP-Response of EAP 389 type=TEAP and sets the version field its highest supported 390 version. 392 2c. If the TEAP peer only supports versions higher than the 393 version proposed by the TEAP server, then use of TEAP will not be 394 possible. In this case, the TEAP peer sends back an EAP-Nak 395 either to negotiate a different EAP type or to indicate no other 396 EAP types are a available. 398 3a. If the TEAP server does not support the version number 399 proposed by the TEAP peer, it it MUST either terminate the 400 conversation with an EAP-Failure or negotiate a new EAP type. 402 3b. If the TEAP server does support the version then the 403 conversation continues using the version proposed by the TEAP 404 peer. 406 The version negotiation procedure guarantees that the TEAP peer and 407 server will agree to the latest version supported by both parties. 408 If version negotiation fails, then use of TEAP will not be possible, 409 and another mutually acceptable EAP method will need to be negotiated 410 if authentication is to proceed. 412 The TEAP version is not protected by TLS; and hence can be modified 413 in transit. In order to detect a modification of the TEAP version, 414 the peers MUST exchange the TEAP version number received during 415 version negotiation using the Crypto-Binding TLV described in 416 Section 4.2.13. The receiver of the Crypto-Binding TLV MUST verify 417 that the version received in the Crypto-Binding TLV matches the 418 version sent by the receiver in the TEAP version negotiation. If the 419 Crypto-Binding TLV fails to be validated, then it is a fatal error 420 and is handled as described in Section 3.6.3. 422 3.2. TEAP Authentication Phase 1: Tunnel Establishment 424 TEAP relies on the TLS handshake [RFC5246] to establish an 425 authenticated and protected tunnel. The TLS version offered by the 426 peer and server MUST be TLS version 1.2 [RFC5246] or later. This 427 version of the TEAP implementation MUST support the following TLS 428 ciphersuites: 430 TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246] 432 TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246] 434 This version of the TEAP implementation SHOULD support the following 435 TLS ciphersuite: 437 TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246] 439 Other ciphersuites MAY be supported. It is REQUIRED that anonymous 440 ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only 441 be used in the case when the inner authentication method provides 442 mutual authentication, key generation, and resistance to man-in-the- 443 middle and dictionary attack. TLS ciphersuites that do not provide 444 confidentiality MUST NOT be used. During the TEAP Phase 1 445 conversation, the TEAP endpoints MAY negotiate TLS compression. 446 During TLS tunnel establishment, TLS extensions MAY be used. For 447 instance, Certificate Status Request extension [RFC6066] and multiple 448 certificate status request extension [RFC6961] can be used to 449 leverage a certificate-status protocol such as OCSP [RFC6960] to 450 check the validity of server certificates. TLS renegotiation 451 indications defined in RFC 5746 [RFC5746] MUST be supported. 453 The EAP server initiates the TEAP conversation with an EAP request 454 containing a TEAP/Start packet. This packet includes a set Start (S) 455 bit, the TEAP version as specified in Section 3.1, and an authority 456 identity TLV. The TLS payload in the initial packet is empty. The 457 authority identity TLV (Authority-ID TLV) is used to provide the peer 458 a hint of the server's identity that may be useful in helping the 459 peer select the appropriate credential to use. Assuming that the 460 peer supports TEAP, the conversation continues with the peer sending 461 an EAP-Response packet with EAP type of TEAP with the Start (S) bit 462 clear and the version as specified in Section 3.1. This message 463 encapsulates one or more TLS handshake messages. If the TEAP version 464 negotiation is successful then the TEAP conversation continues until 465 the EAP server and EAP peer are ready to enter Phase 2. When the 466 full TLS handshake is performed, then the first payload of TEAP Phase 467 2 MAY be sent along with server-finished handshake message to reduce 468 the number of round trips. 470 TEAP implementations MUST support mutual peer authentication during 471 tunnel establishment using the TLS ciphersuites specified in this 472 section. The TEAP peer does not need to authenticate as part of the 473 TLS exchange, but can alternatively be authenticated through 474 additional exchanges carried out in Phase 2. 476 The TEAP tunnel protects peer identity information exchanged during 477 phase 2 from disclosure outside the tunnel. Implementations that 478 wish to provide identity privacy for the peer identity need to 479 carefully consider what information is disclosed outside the tunnel 480 prior to phase 2. TEAP implementations SHOULD support the immediate 481 renegotiation of a TLS session to initiate a new handshake message 482 exchange under the protection of the current cipher suite. This 483 allows support for protection of the peer's identity when using TLS 484 client authentication. An example of the exchanges using TLS 485 renegotiation to protect privacy is shown in Appendix C. 487 The following sections describe resuming a TLS session based on 488 server-side or client-side state. 490 3.2.1. TLS Session Resume Using Server State 492 TEAP session resumption is achieved in the same manner TLS achieves 493 session resume. To support session resumption, the server and peer 494 minimally cache the Session ID, master secret, and ciphersuite. The 495 peer attempts to resume a session by including a valid Session ID 496 from a previous TLS handshake in its ClientHello message. If the 497 server finds a match for the Session ID and is willing to establish a 498 new connection using the specified session state, the server will 499 respond with the same Session ID and proceed with the TEAP Phase 1 500 tunnel establishment based on a TLS abbreviated handshake. After a 501 successful conclusion of the TEAP Phase 1 conversation, the 502 conversation then continues on to Phase 2. 504 3.2.2. TLS Session Resume Using a PAC 506 TEAP supports the resumption of sessions based on server state being 507 stored on the client side using the TLS SessionTicket extension 508 techniques described in [RFC5077]. This version of TEAP supports the 509 provisioning of a ticket called a Protected Access Credential (PAC) 510 through the use of the NewSessionTicket handshake described in 511 [RFC5077], as well as provisioning of a PAC inside the protected 512 tunnel. Implementations MUST support the TLS Ticket Extension 513 [RFC5077] mechanism for distributing a PAC and may provide additional 514 ways to provision the PAC, such as manual configuration. Since the 515 PAC mentioned here is used for establishing the TLS Tunnel, it is 516 more specifically referred to as the Tunnel PAC. The Tunnel PAC is a 517 security credential provided by the EAP server to a peer and 518 comprised of: 520 1. PAC-Key: this is the key used by the peer as the TLS master 521 secret to establish the TEAP Phase 1 tunnel. The PAC-Key is a 522 strong high-entropy at minimum 48-octet key and is typically the 523 master secret from a previous TLS session. The PAC-Key is a 524 secret and MUST be treated accordingly. Otherwise, if leaked, it 525 could lead to user credentials being compromised if sent within 526 the tunnel established using the PAC-Key. In the case that a PAC- 527 Key is provisioned to the peer through another means it MUST have 528 its confidentiality and integrity protected by a mechanism, such 529 as the TEAP phase 2 tunnel. The PAC-Key MUST be stored securely 530 by the peer. 532 2. PAC-Opaque: this is a variable length field containing the ticket 533 that is sent to the EAP server during the TEAP Phase 1 tunnel 534 establishment based on RFC 5077. The PAC-Opaque can only be 535 interpreted by the EAP server to recover the required information 536 for the server to validate the peer's identity and 537 authentication. The PAC-Opaque includes the PAC-Key and other 538 TLS session parameters. It may contain the PAC's peer identity. 539 The PAC-Opaque format and contents are specific to the PAC 540 issuing server. The PAC-Opaque may be presented in the clear, so 541 an attacker MUST NOT be able to gain useful information from the 542 PAC-Opaque itself. The server issuing the PAC-Opaque needs to 543 ensure it is protected with strong cryptographic keys and 544 algorithms. The PAC-Opaque may be distributed using the 545 NewSessionTicket message defined in RFC 5077 or it may be 546 distributed through another mechanism such as the phase 2 TLVs 547 defined in this document. 549 3. PAC-Info: this is an optional variable length field used to 550 provide, at a minimum, the authority identity of the PAC issuer. 551 Other useful but not mandatory information, such as the PAC-Key 552 lifetime, may also be conveyed by the PAC issuing server to the 553 peer during PAC provisioning or refreshment. PAC-Info is not 554 included if the NewSessionTicket message is used to provision the 555 PAC. 557 The use of the PAC is based on the SessionTicket extension defined in 558 [RFC5077]. The EAP server initiates the TEAP conversation as normal. 559 Upon receiving the Authority-ID TLV from the server, the peer checks 560 to see if it has an existing valid PAC-Key and PAC-Opaque for the 561 server. If it does, then it obtains the PAC-Opaque and puts it in 562 the SessionTicket extension in the ClientHello. It is RECOMMENDED in 563 TEAP that the peer include an empty Session ID in a ClientHello 564 containing a PAC-Opaque. This version of TEAP supports the 565 NewSessionTicket Handshake message as described in [RFC5077] for 566 distribution of a new PAC, as well as the provisioning of PAC inside 567 the protected tunnel. If the PAC-Opaque included in the 568 SessionTicket extension is valid and the EAP server permits the 569 abbreviated TLS handshake, it will select the cipher suite from 570 information within the PAC-Opaque and finish with the abbreviated TLS 571 handshake. If the server receives a Session ID and a PAC-Opaque in 572 the SessionTicket extension in a ClientHello, it should place the 573 same Session ID in the ServerHello if it is resuming a session based 574 on the PAC-Opaque. The conversation then proceeds as described in 575 [RFC5077] until the handshake completes or a fatal error occurs. 576 After the abbreviated handshake completes, the peer and the server 577 are ready to commence Phase 2. 579 3.2.3. Transition between Abbreviated and Full TLS Handshake 581 If session resumption based on server-side or client-side state 582 fails, the server can gracefully fall back to a full TLS handshake. 583 If the ServerHello received by the peer contains an empty Session ID 584 or a Session ID that is different than in the ClientHello, the server 585 may fall back to a full handshake. The peer can distinguish the 586 server's intent of negotiating full or abbreviated TLS handshake by 587 checking the next TLS handshake messages in the server response to 588 the ClientHello. If ChangeCipherSpec follows the ServerHello in 589 response to the ClientHello, then the server has accepted the session 590 resumption and intends to negotiate the abbreviated handshake. 591 Otherwise, the server intends to negotiate the full TLS handshake. A 592 peer can request that a new PAC to be provisioned after the full TLS 593 handshake and mutual authentication of the peer and the server. A 594 peer SHOULD NOT request that a new PAC to be provisioned after the 595 abbreviated handshake, as requesting a new session ticket based on 596 resumed session is not permitted. In order to facilitate the 597 fallback to a full handshake the peer SHOULD include cipher suites 598 that allow for a full handshake and possibly PAC provisioning so the 599 server can select one of these in case session resumption fails. An 600 example of the transition is shown in Appendix C. 602 3.3. TEAP Authentication Phase 2: Tunneled Authentication 604 The second portion of the TEAP Authentication occurs immediately 605 after successful completion of Phase 1. Phase 2 occurs even if both 606 peer and authenticator are authenticated in the Phase 1 TLS 607 negotiation. Phase 2 MUST NOT occur if the Phase 1 TLS handshake 608 fails, as that will compromise the security as the tunnel has not 609 been established successfully. Phase 2 consists of a series of 610 requests and responses encapsulated in TLV objects defined in 611 Section 4.2. Phase 2 MUST always end with a Crypto-Binding TLV 612 exchange described in Section 4.2.13 and a protected termination 613 exchange described in Section 3.3.3. The TLV exchange may include 614 the execution of zero or more EAP methods within the protected tunnel 615 as described in Section 3.3.1. A server MAY proceed directly to the 616 protected termination exchange if it does not wish to request further 617 authentication from the peer. However, the peer and server MUST NOT 618 assume that either will skip inner EAP methods or other TLV 619 exchanges, as the other peer might have different security policy. 620 The peer may have roamed to a network that requires conformance with 621 a different authentication policy, or the peer may request the server 622 take additional action (e.g., channel binding) through the use of the 623 Request-Action TLV as defined in Section 4.2.9. 625 3.3.1. EAP Sequences 627 EAP [RFC3748] prohibits use of multiple authentication methods within 628 a single EAP conversation in order to limit vulnerabilities to man- 629 in-the-middle attacks. TEAP addresses man-in-the-middle attacks 630 through support for cryptographic protection of the inner EAP 631 exchange and cryptographic binding of the inner authentication 632 method(s) to the protected tunnel. EAP methods are executed serially 633 in a sequence. This version of TEAP does not support initiating 634 multiple EAP methods simultaneously in parallel. The methods need 635 not be distinct. For example, EAP-TLS could be run twice as an inner 636 method, first using machine credentials followed by a second instance 637 using user credentials. 639 EAP method messages are carried within EAP-Payload TLVs defined in 640 Section 4.2.10. If more than one method is going to be executed in 641 the tunnel, then upon method completion, the server MUST send an 642 Intermediate-Result TLV indicating the result. The peer MUST respond 643 to the Intermediate-Result TLV indicating its result. If the result 644 indicates success, the Intermediate-Result TLV MUST be accompanied by 645 a Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in 646 Section 4.2.13 and Section 5.3. The Intermediate-Result TLVs can be 647 included with other TLVs such as EAP-Payload TLVs starting a new EAP 648 conversation or with the Result TLV used in the protected termination 649 exchange. 651 If both peer and server indicate success, then the method is 652 considered complete. If either indicates failure, then the method is 653 considered failed. The result of failure of an EAP method does not 654 always imply a failure of the overall authentication. If one 655 authentication method fails, the server may attempt to authenticate 656 the peer with a different method. 658 3.3.2. Optional Password Authentication 660 The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT 661 RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with 662 EAP-GTC defined in [RFC3748]. Implementations should instead make 663 use of the password authentication TLVs defined in this 664 specification. The authentication server initiates password 665 authentication by sending a Basic-Password-Auth-Req TLV defined in 666 Section 4.2.14. If the peer wishes to participate in password 667 authentication then it responds with a Basic-Password-Auth-Resp TLV 668 as defined in Section 4.2.15 that contains the username and password. 669 If it does not wish to perform password authentication then it 670 responds with a NAK TLV indicating the rejection of the Basic- 671 Password-Auth-Req TLV. Upon receiving the response, the server 672 indicates the success or failure of the exchange using an 673 Intermediate-Result TLV. Multiple roundtrips of password 674 authentication requests and responses MAY be used to support some 675 "housecleaning" functions such as password change, change pin, etc. 676 before a user is authenticated. 678 3.3.3. Protected Termination and Acknowledged Result Indication 680 A successful TEAP Phase 2 conversation MUST always end in a 681 successful Crypto-Binding TLV and Result TLV exchange. A TEAP server 682 may initiate the Crypto-Binding TLV and Result TLV exchange without 683 initiating any EAP conversation in TEAP Phase 2. After the final 684 Result TLV exchange, the TLS tunnel is terminated and a clear text 685 EAP-Success or EAP-Failure is sent by the server. Peers implementing 686 TEAP MUST NOT accept a clear-text EAP success or failure packet prior 687 to the peer and server reaching synchronized protected result 688 indication. 690 The Crypto-Binding TLV exchange is used to prove that both the peer 691 and server participated in the tunnel establishment and sequence of 692 authentications. It also provides verification of the TEAP type, 693 version negotiated, outer TLVs exchanged before the TLS tunnel 694 establishment. The Crypto-Binding TLV MUST be exchanged and verified 695 before the final Result TLV exchange, regardless whether there is an 696 inner EAP method authentication or not. The Crypto-Binding TLV and 697 Intermediate-Result TLV MUST be included to perform Cryptographic 698 Binding after each successful EAP method in a sequence of one or more 699 EAP methods. The server may send the final Result TLV along with an 700 Intermediate-Result TLV and a Crypto-Binding TLV to indicate its 701 intention to end the conversation. If the peer requires nothing more 702 from the server, it will respond with a Result TLV indicating success 703 accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if 704 necessary. The server then tears down the tunnel and sends a clear 705 text EAP-Success or EAP-Failure. 707 If the peer receives a Result TLV indicating success from the server, 708 but its authentication policies are not satisfied (for example it 709 requires a particular authentication mechanism be run or it wants to 710 request a PAC), it may request further action from the server using 711 the Request-Action TLV. The Request-Action TLV is sent with a Status 712 field indicating what EAP Success/Failure result the peer would 713 expect if the requested action is not granted. The value of the 714 Action field indicates what the peer would like to do next. The 715 format and values for the Request-Action TLV are defined in 716 Section 4.2.9. 718 Upon receiving the Request-Action TLV the server may process the 719 request or ignore it, based on its policy. If the server ignores the 720 request, it proceeds with termination of the tunnel and send the 721 clear text EAP Success or Failure message based on the Status field 722 of the peer's Request-Action TLV. If the server honors and processes 723 the request, it continues with the requested action. The 724 conversation completes with a Result TLV exchange. The Result TLV 725 may be included with the TLV that completes the requested action. 727 Error handling for Phase 2 is discussed in Section 3.6.3. 729 3.4. Determining Peer-Id and Server-Id 731 The Peer-Id and Server-Id [RFC5247] may be determined based on the 732 types of credentials used during either the TEAP tunnel creation or 733 authentication. In the case of multiple peer authentications, all 734 authenticated peer identities and their corresponding identity types 735 (Section 4.2.3) need to be exported. In the case of multiple server 736 authentications, all authenticated server identities need to be 737 exported. 739 When X.509 certificates are used for peer authentication, the Peer-Id 740 is determined by the subject and subjectAltName fields in the peer 741 certificate. As noted in [RFC5280]: 743 The subject field identifies the entity associated with the public 744 key stored in the subject public key field. The subject name MAY 745 be carried in the subject field and/or the subjectAltName 746 extension. If subject naming information is present only in the 747 subjectAltName extension (e.g., a key bound only to an email 748 address or URI), then the subject name MUST be an empty sequence 749 and the subjectAltName extension MUST be critical. 751 Where it is non-empty, the subject field MUST contain an X.500 752 distinguished name (DN). 754 If an inner EAP method is run, then the Peer-Id is obtained from the 755 inner method. 757 When the server uses an X.509 certificate to establish the TLS 758 tunnel, the Server-Id is determined in a similar fashion as stated 759 above for the Peer-Id; e.g., the subject and subjectAltName fields in 760 the server certificate defines the Server-Id. 762 3.5. TEAP Session Identifier 764 The EAP session identifier [RFC5247] is constructed using the tls- 765 unique from the phase 1 outer tunnel at the beginning of phase 2 as 766 defined by section 3.1 of [RFC5929]. The Session-Id is defined as 767 follows: 769 Session-Id = teap_type || tls-unique 771 where teap_type is the EAP method type assigned to TEAP 773 tls-unique = tls-unique from the phase 1 outer tunnel at the 774 beginning of phase 2 as defined by section 3.1 of [RFC5929] 776 || means concatenation 778 3.6. Error Handling 780 TEAP uses the following error handling rules summarized below: 782 1. Errors in the outer EAP packet layer are handled as defined in 783 Section 3.6.1. 785 2. Errors in the TLS layer are communicated via TLS alert messages 786 in all phases of TEAP. 788 3. The Intermediate-Result TLVs carry success or failure indications 789 of the individual EAP methods in TEAP Phase 2. Errors within the 790 EAP conversation in Phase 2 are expected to be handled by 791 individual EAP methods. 793 4. Violations of the Inner TLV rules are handled using Result TLVs 794 together with Error TLVs. 796 5. Tunnel compromised errors (errors caused by Crypto-Binding failed 797 or missing) are handled using Result TLVs and Error TLVs. 799 3.6.1. Outer Layer Errors 801 Errors on the TEAP outer packet layer are handled in the following 802 ways: 804 1. If Outer TLVs are invalid or contain unknown values, they will be 805 ignored. 807 2. The entire TEAP packet will be ignored if other fields (version, 808 length, flags, etc.) are inconsistent with this specification. 810 3.6.2. TLS Layer Errors 812 If the TEAP server detects an error at any point in the TLS Handshake 813 or the TLS layer, the server SHOULD send a TEAP request encapsulating 814 a TLS record containing the appropriate TLS alert message rather than 815 immediately terminating the conversation so as to allow the peer to 816 inform the user of the cause of the failure and possibly allow for a 817 restart of the conversation. The peer MUST send a TEAP response to 818 an alert message. The EAP-Response packet sent by the peer may 819 encapsulate a TLS ClientHello handshake message, in which case the 820 TEAP server MAY allow the TEAP conversation to be restarted, or it 821 MAY contain a TEAP response with a zero-length message, in which case 822 the server MUST terminate the conversation with an EAP-Failure 823 packet. It is up to the TEAP server whether to allow restarts, and 824 if so, how many times the conversation can be restarted. Per TLS 825 [RFC5226], TLS restart is only allowed for non-fatal alerts. A TEAP 826 server implementing restart capability SHOULD impose a limit on the 827 number of restarts, so as to protect against denial-of-service 828 attacks. If the TEAP server does not allow restarts, it MUST 829 terminate the conversation with an EAP-Failure packet. 831 If the TEAP peer detects an error at any point in the TLS layer, the 832 TEAP peer SHOULD send a TEAP response encapsulating a TLS record 833 containing the appropriate TLS alert message. The server may restart 834 the conversation by sending an TEAP request packet encapsulating the 835 TLS HelloRequest handshake message. The peer may allow the TEAP 836 conversation to be restarted or it may terminate the conversation by 837 sending an TEAP response with an zero-length message. 839 3.6.3. Phase 2 Errors 841 Any time the peer or the server finds a fatal error outside of the 842 TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of 843 failure and an Error TLV with the appropriate error code. For errors 844 involving the processing of the sequence of exchanges, such as a 845 violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error 846 code is Unexpected TLVs Exchanged. For errors involving a tunnel 847 compromise, the error-code is Tunnel Compromise Error. Upon sending 848 a Result TLV with a fatal Error TLV the sender terminates the TLS 849 tunnel. Note that a server will still wait for a message from the 850 peer after it sends a failure, however the server does not need to 851 process the contents of the response message. 853 For inner method, retransmission is not needed and SHOULD NOT be 854 attempted, as the outer TLS tunnel can be considered a reliable 855 transport. If there is a non-fatal error handling the inner method, 856 instead of silently dropping the inner method request or response and 857 not responding, the receiving side SHOULD use an Error TLV with error 858 code Inner Method Error to indicate error processing the current 859 inner method. The side receiving the Error TLV MAY decide to start a 860 new inner method instead or send back a Result TLV to terminate the 861 TEAP authentication session. 863 If a server receives a Result TLV of failure with a fatal Error TLV, 864 it MUST send a clear text EAP-Failure. If a peer receives a Result 865 TLV of failure, it MUST respond with a Result TLV indicating failure. 866 If the server has sent a Result TLV of failure, it ignores the peer 867 response, and it MUST send a clear text EAP-Failure. 869 3.7. Fragmentation 871 A single TLS record may be up to 16384 octets in length, but a TLS 872 message may span multiple TLS records, and a TLS certificate message 873 may in principle be as long as 16 MB. This is larger than the 874 maximum size for a message on most media types, therefore it is 875 desirable to support fragmentation. Note that in order to protect 876 against reassembly lockup and denial-of-service attacks, it may be 877 desirable for an implementation to set a maximum size for one such 878 group of TLS messages. Since a typical certificate chain is rarely 879 longer than a few thousand octets, and no other field is likely to be 880 anywhere near as long, a reasonable choice of maximum acceptable 881 message length might be 64 KB. This is still a fairly large message 882 packet size so an TEAP implementation MUST provide its own support 883 for fragmentation and reassembly. Section 3.1 of [RFC3748] discusses 884 determining the MTU usable by EAP and section 4.3 discusses 885 retransmissions in EAP. 887 Since EAP is a lock-step protocol, fragmentation support can be added 888 in a simple manner. In EAP, fragments that are lost or damaged in 889 transit will be retransmitted, and since sequencing information is 890 provided by the Identifier field in EAP, there is no need for a 891 fragment offset field. 893 TEAP fragmentation support is provided through the addition of flag 894 bits within the EAP-Response and EAP-Request packets, as well as a 895 TLS Message Length field of four octets. Flags include the Length 896 included (L), More fragments (M), and TEAP Start (S) bits. The L 897 flag is set to indicate the presence of the four-octet TLS Message 898 Length field, and MUST be set for the first fragment of a fragmented 899 TLS message or set of messages. It MUST NOT be present for any other 900 message. The M flag is set on all but the last fragment. The S flag 901 is set only within the TEAP start message sent from the EAP server to 902 the peer. The TLS Message Length field is four octets, and provides 903 the total length of the TLS message or set of messages that is being 904 fragmented; this simplifies buffer allocation. 906 When a TEAP peer receives an EAP-Request packet with the M bit set, 907 it MUST respond with an EAP-Response with EAP-Type of TEAP and no 908 data. This serves as a fragment ACK. The EAP server MUST wait until 909 it receives the EAP-Response before sending another fragment. In 910 order to prevent errors in processing of fragments, the EAP server 911 MUST increment the Identifier field for each fragment contained 912 within an EAP-Request, and the peer MUST include this Identifier 913 value in the fragment ACK contained within the EAP-Response. 914 Retransmitted fragments will contain the same Identifier value. 916 Similarly, when the TEAP server receives an EAP-Response with the M 917 bit set, it responds with an EAP-Request with EAP-Type of TEAP and no 918 data. This serves as a fragment ACK. The EAP peer MUST wait until 919 it receives the EAP-Request before sending another fragment. In 920 order to prevent errors in the processing of fragments, the EAP 921 server MUST increment the Identifier value for each fragment ACK 922 contained within an EAP-Request, and the peer MUST include this 923 Identifier value in the subsequent fragment contained within an EAP- 924 Response. 926 3.8. Peer Services 928 Several TEAP services including server unauthenticated provisioning, 929 PAC provisioning, certificate provisioning and channel binding depend 930 on the peer trusting the TEAP server. Peers MUST authenticate the 931 server before these peer services are used. TEAP peer 932 implementations MUST have a configuration where authentication fails 933 if server authentication cannot be achieved. In many cases the 934 server will want to authenticate the peer before providing these 935 services as well 937 TEAP peers MUST track whether server authentication has taken place. 938 Server authentication results if the peer trusts the provided server 939 certificate. Typically this involves both validating the certificate 940 to a trust anchor and confirming the entity named by the certificate 941 is the intended server. Server authentication also results when the 942 procedures of Section 3.2 are used to resume a session in which the 943 the peer and server was previously mutually authenticated. 944 Alternatively, peer services can be used if an inner EAP method 945 providing mutual authentication and an Extended Master Session Key 946 (EMSK) is executed and cryptographic binding with the EMSK compound 947 MAC is correctly validated (Section 4.2.13). This is further 948 described in Section 3.8.3. 950 An additional complication arises when a tunnel method authenticates 951 multiple parties such as authenticating both the peer machine and the 952 peer user to the EAP server. Depending on how authentication is 953 achieved, only some of these parties may have confidence in it. For 954 example if a strong shared secret is used to mutually authenticate 955 the user and the EAP server, the machine may not have confidence that 956 the EAP server is the authenticated party if the machine cannot trust 957 the user not to disclose the shared secret to an attacker. In these 958 cases, the parties who participate in the authentication need to be 959 considered when evaluating whether to use peer services. 961 3.8.1. PAC Provisioning 963 To request provisioning of a PAC, a peer sends a PAC TLV as defined 964 in Section 4.2.12 containing a PAC Attribute as defined in 965 Section 4.2.12.1 of PAC Type set to the appropriate value. The peer 966 MUST successfully authenticate the EAP server and validate the the 967 Crypto-Binding TLV as defined in Section 4.2.13 before issuing the 968 request. The peer MUST send separate PAC TLVs for each type of PAC 969 it wants to be provisioned. Multiple PAC TLVs can be sent in the 970 same packet or different packets. The EAP server will send the PACs 971 after its internal policy has been satisfied, or it MAY ignore the 972 request or request additional authentications if its policy dictates. 973 The server MAY cache the request and provision the PACs requested 974 after all of its internal policies have been satisfied. If a peer 975 receives a PAC with an unknown type, it MUST ignore it. 977 A PAC-TLV containing PAC-Acknowledge attribute MUST be sent by the 978 peer to acknowledge the receipt of the Tunnel PAC. A PAC-TLV 979 containing PAC-Acknowledge attribute MUST NOT be used by the peer to 980 acknowledge the receipt of other types of PACs. If the peer receives 981 a PAC TLV with an unknown attribute, it SHOULD ignore the unknown 982 attribute. 984 3.8.2. Certificate Provisioning Within the Tunnel 986 Provisioning of a peer's certificate is supported in TEAP by 987 performing the Simple PKI Request/Response from [RFC5272] using 988 PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI 989 Request using a PKCS#10 CertificateRequest [RFC2986] encoded into the 990 body of a PKCS#10 TLV (see Section 4.2.17). The TEAP Server issues a 991 Simple PKI Response using a PKCS#7 [RFC2315] degenerate "certs-only" 992 message encoded into the body of a PKCS#7 TLV (see Section 4.2.16), 993 only after an authentication method has run and provided an identity 994 proof on the peer prior to a certificate is being issued. 996 In order to provide linking identity and proof-of-possession by 997 including information specific to the current authenticated TLS 998 session within the signed certification request, the peer generating 999 the request SHOULD obtain the tls-unique value from the TLS subsystem 1000 as defined in Channel Bindings for TLS [RFC5929]. The TEAP peer 1001 operations between obtaining the tls_unique value through generation 1002 of the CSR that contains the current tls_unique value and the 1003 subsequent verification of this value by the TEAP server are the 1004 "phases of the application protocol during which application- layer 1005 authentication occurs" that are protected by the synchronization 1006 interoperability mechanism described in the Channel Bindings for TLS 1007 [RFC5929] section 3.1 interoperability notes. When performing 1008 renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used. 1010 The tls-unique value is base 64-encoded as specified in Section 4 of 1011 [RFC4648] and the resulting string is placed in the certification 1012 request challenge-password field ( [RFC2985], Section 5.4.1). The 1013 challenge-password field is limited to 255 bytes (section 7.4.9 of 1014 [RFC5246] indicates that no existing cipher suite would result in an 1015 issue with this limitation). If tls-unique information is not 1016 embedded within the certification request the challenge-password 1017 field MUST be empty to indicate that the peer did not include the 1018 optional channel-binding information (any value submitted is verified 1019 by the server as tls-unique information). 1021 The server SHOULD verify the tls-unique information. This ensures 1022 that the authenticated TEAP peer is in possession of the private key 1023 used to sign the certification request. 1025 The Simple PKI Request/Response generation and processing rules of 1026 [RFC5272] SHALL apply to TEAP, with the exception of error 1027 conditions. In the event of an error, the TEAP Server SHOULD respond 1028 with an Error TLV using the most descriptive error code possible; it 1029 MAY ignore the PKCS#10 request which generated the error. 1031 3.8.3. Server Unauthenticated Provisioning Mode 1033 In Server Unauthenticated Provisioning Mode, an unauthenticated 1034 tunnel is established in phase 1 and the peer and server negotiate an 1035 EAP method in phase 2 that supports mutual authentication and key 1036 derivation that is resistant to attacks such as Man-in-the-middle and 1037 dictionary attacks. This provisioning mode enables the bootstrapping 1038 of peers when the peer lacks a strong credential usable for mutual 1039 authentication with the server during phase 1. This includes both 1040 cases of where the cipher suite negotiated does not provide 1041 authentication or the cipher suite negotiated provides the 1042 authentication but the peer is unable to validate the identity of the 1043 server for some reason. 1045 Upon successful completion of the EAP method in phase 2, the peer and 1046 server exchange a Crypto-Binding TLV to bind the inner method with 1047 the outer tunnel and ensure that a man-in-the-middle attack has not 1048 been attempted. 1050 Support for the Server Unauthenticated Provisioning Mode is optional. 1051 The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when 1052 using server unauthenticated mode, but other anonymous ciphersuites 1053 MAY be supported as long as the TLS pre-master secret is generated 1054 from contribution from both peers. Phase 2 EAP methods used in 1055 Server Unauthenticated Provisioning Mode MUST provide mutual 1056 authentication, key generation, and be resistant to dictionary 1057 attack. Example inner methods include EAP-pwd [RFC5931] and EAP-EKE 1058 [RFC6124]. 1060 3.8.4. Channel Binding 1062 [RFC6677] defines EAP channel bindings to solve the "lying NAS" and 1063 the "lying provider" problems, using a process in which the EAP peer 1064 gives information about the characteristics of the service provided 1065 by the authenticator to the AAA server protected within the EAP 1066 method. This allows the server to verify the authenticator is 1067 providing information to the peer that is consistent with the 1068 information received from this authenticator as well as the 1069 information stored about this authenticator. 1071 TEAP supports EAP channel binding using the Channel-Binding TLV 1072 defined in Section 4.2.7. If the TEAP server wants to request the 1073 channel binding information from the peer, it sends an empty Channel- 1074 Binding TLV to indicate the request. The peer responds to the 1075 request by sending a Channel-Binding TLV containing channel binding 1076 message as defined in [RFC6677]. The server validates the channel 1077 binding message and sends back a Channel-Binding TLV with a result 1078 code. If the server didn't initiate the channel binding request and 1079 peer still wants to send the channel binding information to the 1080 server, it can do that by using the Request-Action TLV along with the 1081 Channel-Binding TLV.Peer MUST only sends channel binding information 1082 after it has successfully authenticated the server and established 1083 the protected tunnel. 1085 4. Message Formats 1087 The following sections describe the message formats used in TEAP. 1088 The fields are transmitted from left to right in network byte order. 1090 4.1. TEAP Message Format 1092 A summary of the TEAP Request/Response packet format is shown below. 1094 0 1 2 3 1095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Code | Identifier | Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type | Flags | Ver | Message Length : 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 : Message Length | Outer TLV Length 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 : Outer TLV Length | TLS Data... 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Outer TLVs... 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 Code 1110 The code field is one octet in length defined as follows: 1112 1 Request 1114 2 Response 1116 Identifier 1117 The Identifier field is one octet and aids in matching responses 1118 with requests. The Identifier field MUST be changed on each 1119 Request packet. The Identifier field in the Response packet MUST 1120 match the Identifier field from the corresponding request. 1122 Length 1124 The Length field is two octets and indicates the length of the 1125 EAP packet including the Code, Identifier, Length, Type, Flags, 1126 Ver, Message Length, TLS Data, and Outer TLVs fields. Octets 1127 outside the range of the Length field should be treated as Data 1128 Link Layer padding and should be ignored on reception. 1130 Type 1132 TBD for TEAP 1134 Flags 1136 0 1 2 3 4 1137 +-+-+-+-+-+ 1138 |L M S O R| 1139 +-+-+-+-+-+ 1141 L Length included; set to indicate the presence of the four 1142 octet Message Length field. It MUST be present for the first 1143 fragment of a fragmented message. It MUST NOT be present for 1144 any other message 1146 M More fragments; set on all but the last fragment 1148 S TEAP start; set in a TEAP Start message sent from the server 1149 to the peer 1151 O Outer TLV length included; set to indicate the presence of the 1152 four-octet Outer TLV Length field. It MUST be present only in 1153 the initial request and response messages. If the initial 1154 message is fragmented, then it MUST be present only on the 1155 first fragment 1157 R Reserved (MUST be zero and ignored upon receipt) 1159 Ver 1160 This field contains the version of the protocol. This document 1161 describes version 1 (001 in binary) of TEAP. 1163 Message Length 1165 The Message Length field is four octets, and is present only if 1166 the L bit is set. This field provides the total length of the 1167 message that may be fragmented over the data fields of multiple 1168 packets. 1170 Outer TLV Length 1172 The Outer TLV Length field is four octets, and is present only if 1173 the O bit is set. This field provides the total length of the 1174 Outer TLVs if present. 1176 TLS Data 1178 When the Data field is present, it consists of an encapsulated 1179 TLS packet in TLS record format. A TEAP packet with Flags and 1180 Version fields, but with zero length TLS data field, is used to 1181 indicate TEAP acknowledgement for either a fragmented message, a 1182 TLS Alert message or a TLS Finished message. 1184 Outer TLVs 1186 The Outer TLVs consist of the optional data used to help 1187 establishing the TLS tunnel in TLV format. They are only allowed 1188 in the first two messages in the TEAP protocol. That is the 1189 first EAP server to peer message and first peer to EAP server 1190 message. The start of the Outer TLVs can be derived from the EAP 1191 Length field and Outer TLV Length field. 1193 4.2. TEAP TLV Format and Support 1195 The TLVs defined here are standard Type-Length-Value (TLV) objects. 1196 The TLV objects could be used to carry arbitrary parameters between 1197 EAP peer and EAP server within the protected TLS tunnel. 1199 The EAP peer may not necessarily implement all the TLVs supported by 1200 the EAP server. To allow for interoperability, TLVs are designed to 1201 allow an EAP server to discover if a TLV is supported by the EAP 1202 peer, using the NAK TLV. The mandatory bit in a TLV indicates 1203 whether support of the TLV is required. If the peer or server does 1204 not support a TLV marked mandatory, then it MUST send a NAK TLV in 1205 the response, and all the other TLVs in the message MUST be ignored. 1206 If an EAP peer or server finds an unsupported TLV that is marked as 1207 optional, it can ignore the unsupported TLV. It MUST NOT send an NAK 1208 TLV for a TLV that is not marked mandatory. If all TLVs in a message 1209 are marked optional and none are understood by the peer, then a NAK 1210 TLV or Result TLV could be sent to the other side in order to 1211 continue the conversation. 1213 Note that a peer or server may support a TLV with the mandatory bit 1214 set, but may not understand the contents. The appropriate response 1215 to a supported TLV with content that is not understood is defined by 1216 the individual TLV specification. 1218 EAP implementations compliant with this specification MUST support 1219 TLV exchanges, as well as the processing of mandatory/optional 1220 settings on the TLV. Implementations conforming to this 1221 specification MUST support the following TLVs: 1223 Authority-ID TLV 1225 Identity-Type TLV 1227 Result TLV 1229 NAK TLV 1231 Error TLV 1233 Request-Action TLV 1235 EAP-Payload TLV 1237 Intermediate-Result TLV 1239 Crypto-Binding TLV 1241 Basic-Password-Auth-Req TLV 1243 Basic-Password-Auth-Resp TLV 1245 4.2.1. General TLV Format 1247 TLVs are defined as described below. The fields are transmitted from 1248 left to right. 1250 0 1 2 3 1251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 |M|R| TLV Type | Length | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Value... 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 M 1260 0 Optional TLV 1262 1 Mandatory TLV 1264 R 1266 Reserved, set to zero (0) 1268 TLV Type 1270 A 14-bit field, denoting the TLV type. Allocated Types 1271 include: 1273 0 Unassigned 1275 1 Authority-ID TLV (Section 4.2.2) 1277 2 Identity-Type TLV (Section 4.2.3) 1279 3 Result TLV (Section 4.2.4) 1281 4 NAK TLV (Section 4.2.5) 1283 5 Error TLV (Section 4.2.6) 1285 6 Channel-Binding TLV (Section 4.2.7) 1287 7 Vendor-Specific TLV (Section 4.2.8) 1289 8 Request-Action TLV (Section 4.2.9) 1290 9 EAP-Payload TLV (Section 4.2.10) 1292 10 Intermediate-Result TLV (Section 4.2.11) 1294 11 PAC TLV (Section 4.2.12) 1296 12 Crypto-Binding TLV (Section 4.2.13) 1298 13 Basic-Password-Auth-Req TLV (Section 4.2.14) 1300 14 Basic-Password-Auth-Resp TLV (Section 4.2.15) 1302 15 PKCS#7 TLV (Section 4.2.16) 1304 16 PKCS#10 TLV (Section 4.2.17) 1306 17 Server-Trusted-Root TLV (Section 4.2.18) 1308 Length 1310 The length of the Value field in octets. 1312 Value 1314 The value of the TLV. 1316 4.2.2. Authority-ID TLV 1318 0 1 2 3 1319 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 |M|R| TLV Type | Length | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | ID... 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 M 1328 Mandatory, set to one (1) 1330 R 1332 Reserved, set to zero (0) 1334 TLV Type 1336 1 for Authority-ID 1338 Length 1340 The Length filed is two octets, which contains the length of 1341 the ID field in octets. 1343 ID 1345 Hint of the identity of the server, to help the peer to match 1346 the credentials available for the server. It should be unique 1347 across the deployment. 1349 4.2.3. Identity-Type TLV 1351 The Identity-Type TLV allows an EAP server to send a hint to help the 1352 EAP peer select the right type of identity; for example; user or 1353 machine. TEAPv1 implementations MUST support this TLV. Only one 1354 Identity-Type TLV SHOULD be present in the TEAP request or response 1355 packet. The Identity-Type TLV request MUST come with an EAP-Payload 1356 TLV or Basic-Password-Auth-Req TLV. If the EAP peer does have an 1357 identity corresponding to the identity type requested, then the peer 1358 SHOULD respond with an Identity-Type TLV with the requested type. If 1359 the Identity-Type field does not contain one of the known values or 1360 if the EAP peer does not have an identity corresponding to the 1361 identity type requested, then the peer SHOULD respond with an 1362 Identity-Type TLV with the one of available identity types. If the 1363 server receives an identity type in the response that does not match 1364 the requested type, then the peer does not possess the requested 1365 credential type and the server SHOULD proceed with authentication for 1366 the credential type proposed by the peer or proceed with requesting 1367 another credential type, or simply apply the network policy based on 1368 the configured policy, e.g., sending Result TLV with Failure. 1370 The Identity-Type TLV is defined as follows: 1372 0 1 2 3 1373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 |M|R| TLV Type | Length | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Identity-Type | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 M 1381 0 (Optional) 1383 R 1385 Reserved, set to zero (0) 1387 TLV Type 1389 2 for Identity-Type TLV 1391 Length 1393 2 1395 Identity-Type 1397 The Identity-Type field is two octets. Values include: 1399 1 User 1401 2 Machine 1403 4.2.4. Result TLV 1405 The Result TLV provides support for acknowledged success and failure 1406 messages for protected termination within TEAP. If the Status field 1407 does not contain one of the known values, then the peer or EAP server 1408 MUST treat this as a fatal error of Unexpected TLVs Exchanged. The 1409 behavior of the Result TLV is further discussed in Section 3.3.3 and 1410 Section 3.6.3. A Result TLV indicating failure MUST NOT be 1411 accompanied by the following TLVs: NAK, EAP-Payload TLV, or Crypto- 1412 Binding TLV. The Result TLV is defined as follows: 1414 0 1 2 3 1415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 |M|R| TLV Type | Length | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Status | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 M 1424 Mandatory, set to one (1) 1426 R 1428 Reserved, set to zero (0) 1430 TLV Type 1432 3 for Result TLV 1434 Length 1436 2 1438 Status 1440 The Status field is two octets. Values include: 1442 1 Success 1444 2 Failure 1446 4.2.5. NAK TLV 1448 The NAK TLV allows a peer to detect TLVs that are not supported by 1449 the other peer. A TEAP packet can contain 0 or more NAK TLVs. A NAK 1450 TLV should not be accompanied by other TLVs. A NAK TLV MUST NOT be 1451 sent in response to a message containing a Result TLV, instead a 1452 Result TLV of failure should be sent indicating failure and an Error 1453 TLV of Unexpected TLVs Exchanged. The NAK TLV is defined as follows: 1455 0 1 2 3 1456 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 |M|R| TLV Type | Length | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Vendor-Id | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | NAK-Type | TLVs... 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 M 1467 Mandatory, set to one (1) 1469 R 1471 Reserved, set to zero (0) 1473 TLV Type 1475 4 for NAK TLV 1477 Length 1479 >=6 1481 Vendor-Id 1483 The Vendor-Id field is four octets, and contains the Vendor-Id 1484 of the TLV that was not supported. The high-order octet is 0 1485 and the low-order three octets are the Structure of Management 1486 Information (SMI) Network Management Private Enterprise Code of 1487 the Vendor in network byte order. The Vendor-Id field MUST be 1488 zero for TLVs that are not Vendor-Specific TLVs. 1490 NAK-Type 1491 The NAK-Type field is two octets. The field contains the Type 1492 of the TLV that was not supported. A TLV of this Type MUST 1493 have been included in the previous packet. 1495 TLVs 1497 This field contains a list of zero or more TLVs, each of which 1498 MUST NOT have the mandatory bit set. These optional TLVs are 1499 for future extensibility to communicate why the offending TLV 1500 was determined to be unsupported. 1502 4.2.6. Error TLV 1504 The Error TLV allows an EAP peer or server to indicate errors to the 1505 other party. A TEAP packet can contain 0 or more Error TLVs. The 1506 Error-Code field describes the type of error. Error Codes 1-999 1507 represent successful outcomes (informative messages), 1000-1999 1508 represent warnings, and codes 2000-2999 represent fatal errors. A 1509 fatal Error TLV MUST be accompanied by a Result TLV indicating 1510 failure and the conversation is terminated as described in 1511 Section 3.6.3. 1513 Many of the error codes below refer to errors in inner method 1514 processing that may be retrieved if made available by the inner 1515 method. Implementations MUST take care that error messages do not 1516 reveal too much information to an attacker. For example, the usage 1517 of error message 1031 (User account credentials incorrect) is NOT 1518 RECOMMENDED, because it allows an attacker to determine valid 1519 usernames by differentiating this response from other responses. It 1520 should only be used for troubleshooting purposes. 1522 The Error TLV is defined as follows: 1524 0 1 2 3 1525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 |M|R| TLV Type | Length | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Error-Code | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 M 1533 Mandatory, set to one (1) 1535 R 1537 Reserved, set to zero (0) 1539 TLV Type 1541 5 for Error TLV 1543 Length 1545 4 1547 Error-Code 1549 The Error-Code field is four octets. Currently defined values 1550 for Error-Code include: 1552 1 User account expires soon 1554 2 User account credential expires soon 1556 3 User account authorisations change soon 1558 4 Clock skew detected 1560 5 Contact administrator 1562 6 User account credentials change required 1564 1001 Inner Method Error 1566 1002 Unspecified authentication infrastructure problem 1568 1003 Unspecified authentication failure 1570 1004 Unspecified authorisation failure 1572 1005 User account credentials unavailable 1574 1006 User account expired 1575 1007 User account locked: try again later 1577 1008 User account locked: admin intervention required 1579 1009 Authentication infrastructure unavailable 1581 1010 Authentication infrastructure not trusted 1583 1011 Clock skew too great 1585 1012 Invalid inner realm 1587 1013 Token out of sync: administrator intervention required 1589 1014 Token out of sync: PIN change required 1591 1015 Token revoked 1593 1016 Tokens exhausted 1595 1017 Challenge expired 1597 1018 Challenge algorithm mismatch 1599 1019 Client certificate not supplied 1601 1020 Client certificate rejected 1603 1021 Realm mismatch between inner and outer identity 1605 1022 Unsupported Algorithm In Certificate Signing Request 1607 1023 Unsupported Extension In Certificate Signing Request 1609 1024 Bad Identity In Certificate Signing Request 1611 1025 Bad Certificate Signing Request 1613 1026 Internal CA Error 1615 1027 General PKI Error 1617 1028 Inner method's channel binding data required but not 1618 supplied 1620 1029 Inner method's channel binding data did not include 1621 required information 1622 1030 Inner method's channel binding failed 1624 1031 User account credentials incorrect [USAGE NOT 1625 RECOMMENDED] 1627 2001 Tunnel Compromise Error 1629 2002 Unexpected TLVs Exchanged 1631 4.2.7. Channel-Binding TLV 1633 The Channel-Binding TLV provides a mechanism for carrying channel 1634 binding data from the peer to the EAP server and a channel binding 1635 response from the EAP server to the peer as described in [RFC6677]. 1636 TEAPv1 implementations MAY support this TLV, which cannot be 1637 responded to with a NAK TLV. If the Channel-Binding data field does 1638 not contain one of the known values or if the EAP server does not 1639 support this TLV, then the server MUST ignore the value. The 1640 Channel-Binding TLV is defined as follows: 1642 0 1 2 3 1643 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 |M|R| TLV Type | Length | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Data ... 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 M 1652 0 (Optional) 1654 R 1656 Reserved, set to zero (0) 1658 TLV Type 1660 6 for Channel-Binding TLV 1662 Length 1664 variable 1666 Data 1668 The data field contains a channel-binding message as defined in 1669 section 5.3 of [RFC6677]. 1671 4.2.8. Vendor-Specific TLV 1673 The Vendor-Specific TLV is available to allow vendors to support 1674 their own extended attributes not suitable for general usage. A 1675 Vendor-Specific TLV attribute can contain one or more TLVs, referred 1676 to as Vendor TLVs. The TLV-type of a Vendor-TLV is defined by the 1677 vendor. All the Vendor TLVs inside a single Vendor-Specific TLV 1678 belong to the same vendor. There can be multiple Vendor-Specific 1679 TLVs from different vendors in the same message. Error handling in 1680 the Vendor TLV could use vendor's own specific error handling 1681 mechanism or use the standard TEAP error codes defined. 1683 Vendor TLVs may be optional or mandatory. Vendor TLVs sent with 1684 Result TLVs MUST be marked as optional. If the Vendor-Specific TLV 1685 is marked as mandatory, then it is expected that the receiving side 1686 needs to recognize the vendor ID, parse all Vendor TLVs within and 1687 deal with error handling within the Vendor-Specific TLV as defined by 1688 the vendor. 1690 The Vendor-Specific TLV is defined as follows: 1692 0 1 2 3 1693 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 |M|R| TLV Type | Length | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | Vendor-Id | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | Vendor TLVs.... 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 M 1704 0 or 1 1706 R 1708 Reserved, set to zero (0) 1710 TLV Type 1712 7 for Vendor Specific TLV 1714 Length 1716 4 + cumulative length of all included Vendor TLVs 1718 Vendor-Id 1720 The Vendor-Id field is four octets, and contains the Vendor-Id 1721 of the TLV. The high-order octet is 0 and the low-order 3 1722 octets are the SMI Network Management Private Enterprise Code 1723 of the Vendor in network byte order. 1725 Vendor TLVs 1727 This field is of indefinite length. It contains vendor- 1728 specific TLVs, in a format defined by the vendor. 1730 4.2.9. Request-Action TLV 1732 The Request-Action TLV MAY be sent by both the peer and the server in 1733 response to a successful or failure Result TLV. It allows the peer 1734 or server to request the other side to negotiate additional EAP 1735 methods or process TLVs specified in the response packet. The 1736 receiving side MUST process this TLV. The processing for the TLV is 1737 as follows: 1739 The receiving entity MAY choose to process any of the TLVs that 1740 are included in the message. 1742 If the receiving entity chooses NOT to process any TLV in the 1743 list, then it sends back a Result TLV with the same code in the 1744 Status field of the Request-Action TLV. 1746 If multiple Request-Action TLVs are in the request, the session 1747 can continue if any of the TLVs in any Request-Action TLV is 1748 processed. 1750 If multiple Request-Action TLVs are in the request and none of 1751 them is processed, then the most fatal status should be used in 1752 the Result TLV returned. If a status code in the Request-Action 1753 TLV is not understood by the receiving entity, then it should be 1754 treated as a fatal error. 1756 After processing the TLVs or EAP method in the request, another 1757 round of Result TLV exchange would occur to synchronize the final 1758 status on both sides. 1760 The peer or the server MAY send multiple Request-Action TLVs to the 1761 other side. Two Request-Action TLVs MUST NOT occur in the same TEAP 1762 packet if they have the same Status value. The order of processing 1763 multiple Request-Action TLVs is implementation dependent. If the 1764 receiving side process the optional (non-fatal) items first, it is 1765 possible that the fatal items will disappear at a later time. If the 1766 receiving side processes the fatal items first, the communication 1767 time will be shorter. 1769 The peer or the server MAY return a new set of Request-Action TLVs 1770 after one or more of the requested items has been processed and the 1771 other side has signaled it wants to end the EAP conversation. 1773 The Request-Action TLV is defined as follows: 1775 0 1 2 3 1776 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 |M|R| TLV Type | Length | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Status | Action | TLVs.... 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+- 1783 M 1785 Mandatory set to one (1) 1787 R 1789 Reserved, set to zero (0) 1791 TLV Type 1793 8 for Request-Action TLV 1795 Length 1797 2 + cumulative length of all included TLVs 1799 Status 1801 The Status field is one octet. This indicates the result if the 1802 server does not process the action requested by the peer. Values 1803 include: 1805 1 Success 1807 2 Failure 1809 Action 1811 The Action field is one octet. Values include: 1813 1 Process-TLV 1815 2 Negotiate-EAP 1817 TLVs 1819 This field is of indefinite length. It contains TLVs that the 1820 peer wants the server to process. 1822 4.2.10. EAP-Payload TLV 1824 To allow piggybacking an EAP request or response with other TLVs, the 1825 EAP-Payload TLV is defined, which includes an encapsulated EAP packet 1826 and a list of optional TLVs. The optional TLVs are provided for 1827 future extensibility to provide hints about the current EAP 1828 authentication. Only one EAP-Payload TLV is allowed in a message. 1829 The EAP-Payload TLV is defined as follows: 1831 0 1 2 3 1832 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 |M|R| TLV Type | Length | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | EAP packet... 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | TLVs... 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 M 1842 Mandatory, set to one (1) 1844 R 1846 Reserved, set to zero (0) 1848 TLV Type 1850 9 for EAP-Payload TLV 1852 Length 1854 length of embedded EAP packet + cumulative length of additional 1855 TLVs 1857 EAP packet 1859 This field contains a complete EAP packet, including the EAP 1860 header (Code, Identifier, Length, Type) fields. The length of 1861 this field is determined by the Length field of the 1862 encapsulated EAP packet. 1864 TLVs 1866 This (optional) field contains a list of TLVs associated with 1867 the EAP packet field. The TLVs MUST NOT have the mandatory bit 1868 set. The total length of this field is equal to the Length 1869 field of the EAP-Payload TLV, minus the Length field in the EAP 1870 header of the EAP packet field. 1872 4.2.11. Intermediate-Result TLV 1874 The Intermediate-Result TLV provides support for acknowledged 1875 intermediate Success and Failure messages between multiple inner EAP 1876 methods within EAP. An Intermediate-Result TLV indicating success 1877 MUST be accompanied by a Crypto-Binding TLV. The optional TLVs 1878 associated with this TLV are provided for future extensibility to 1879 provide hints about the current result. The Intermediate-Result TLV 1880 is defined as follows: 1882 0 1 2 3 1883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 |M|R| TLV Type | Length | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | Status | TLVs... 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 M 1892 Mandatory, set to one (1) 1894 R 1896 Reserved, set to zero (0) 1898 TLV Type 1900 10 for Intermediate-Result TLV 1902 Length 1904 2 + cumulative length of the embedded associated TLVs 1906 Status 1908 The Status field is two octets. Values include: 1910 1 Success 1912 2 Failure 1914 TLVs 1916 This field is of indeterminate length, and contains zero or 1917 more of the TLVs associated with the Intermediate Result TLV. 1918 The TLVs in this field MUST NOT have the mandatory bit set. 1920 4.2.12. PAC TLV Format 1922 The PAC TLV provides support for provisioning the Protected Access 1923 Credential (PAC). The PAC TLV carries the PAC and related 1924 information within PAC attribute fields. Additionally, the PAC TLV 1925 MAY be used by the peer to request provisioning of a PAC of the type 1926 specified in the PAC Type PAC attribute. The PAC TLV MUST only be 1927 used in a protected tunnel providing encryption and integrity 1928 protection. A general PAC TLV format is defined as follows: 1930 0 1 2 3 1931 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 |M|R| TLV Type | Length | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | PAC Attributes... 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 M 1940 0 or 1 1942 R 1944 Reserved, set to zero (0) 1946 TLV Type 1948 11 - PAC TLV 1950 Length 1952 Two octets containing the length of the PAC attributes field 1953 in octets. 1955 PAC Attributes 1957 A list of PAC attributes in the TLV format. 1959 4.2.12.1. Formats for PAC Attributes 1961 Each PAC attribute in a PAC TLV is formatted as a TLV defined as 1962 follows: 1964 0 1 2 3 1965 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Type | Length | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Value... 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 Type 1974 The Type field is two octets, denoting the attribute type. 1975 Allocated Types include: 1977 1 - PAC-Key 1978 2 - PAC-Opaque 1979 3 - PAC-Lifetime 1980 4 - A-ID 1981 5 - I-ID 1982 6 - Reserved 1983 7 - A-ID-Info 1984 8 - PAC-Acknowledgement 1985 9 - PAC-Info 1986 10 - PAC-Type 1988 Length 1990 Two octets containing the length of the Value field in 1991 octets. 1993 Value 1995 The value of the PAC attribute. 1997 4.2.12.2. PAC-Key 1999 The PAC-Key is a secret key distributed in a PAC attribute of type 2000 PAC-Key. The PAC-Key attribute is included within the PAC TLV 2001 whenever the server wishes to issue or renew a PAC that is bound to a 2002 key such as a Tunnel PAC. The key is a randomly generated octet 2003 string, which is 48 octets in length. The generator of this key is 2004 the issuer of the credential, which is identified by the Authority 2005 Identifier (A-ID). 2007 0 1 2 3 2008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | Type | Length | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | | 2013 ~ Key ~ 2014 | | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 Type 2019 1 - PAC-Key 2021 Length 2023 2-octet length indicating the length of the key 2025 Key 2027 The value of the PAC-Key. 2029 4.2.12.3. PAC-Opaque 2031 The PAC-Opaque attribute is included within the PAC TLV whenever the 2032 server wishes to issue or renew a PAC. 2034 The PAC-Opaque is opaque to the peer and thus the peer MUST NOT 2035 attempt to interpret it. A peer that has been issued a PAC-Opaque by 2036 a server stores that data and presents it back to the server 2037 according to its PAC Type. The Tunnel PAC is used in the ClientHello 2038 SessionTicket extension field defined in [RFC5077]. If a peer has 2039 opaque data issued to it by multiple servers, then it stores the data 2040 issued by each server separately according to the A-ID. This 2041 requirement allows the peer to maintain and use each opaque datum as 2042 an independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque 2043 identified by the A-ID. As there is a one-to-one correspondence 2044 between the PAC-Key and PAC-Opaque, the peer determines the PAC-Key 2045 and corresponding PAC-Opaque based on the A-ID provided in the TEAP/ 2046 Start message and the A-ID provided in the PAC-Info when it was 2047 provisioned with a PAC-Opaque. 2049 The PAC-Opaque attribute format is summarized as follows: 2051 0 1 2 3 2052 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | Type | Length | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | Value ... 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 Type 2061 2 - PAC-Opaque 2063 Length 2065 The Length filed is two octets, which contains the length of 2066 the Value field in octets. 2068 Value 2070 The Value field contains the actual data for the PAC-Opaque. 2071 It is specific to the server implementation. 2073 4.2.12.4. PAC-Info 2075 The PAC-Info is comprised of a set of PAC attributes as defined in 2076 Section 4.2.12.1. The PAC-Info attribute MUST contain the A-ID, A 2077 -ID-Info, and PAC-Type attributes. Other attributes MAY be included 2078 in the PAC-Info to provide more information to the peer. The PAC- 2079 Info attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, 2080 PAC-Info, or PAC-Opaque attributes. The PAC-Info attribute is 2081 included within the PAC TLV whenever the server wishes to issue or 2082 renew a PAC. 2084 0 1 2 3 2085 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | Type | Length | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 | Attributes... 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 Type 2094 9 - PAC-Info 2096 Length 2098 2-octet Length field containing the length of the attributes 2099 field in octets. 2101 Attributes 2103 The attributes field contains a list of PAC attributes. Each 2104 mandatory and optional field type is defined as follows: 2106 3 - PAC-LIFETIME 2108 This is a 4-octet quantity representing the expiration time 2109 of the credential expressed as the number of seconds, 2110 excluding leap seconds, after midnight UTC, January 1, 1970. 2111 This attribute MAY be provided to the peer as part of the 2112 PAC-Info. 2114 4 - A-ID 2116 The A-ID is the identity of the authority that issued the 2117 PAC. The A-ID is intended to be unique across all issuing 2118 servers to avoid namespace collisions. The A-ID is used by 2119 the peer to determine which PAC to employ. The A-ID is 2120 treated as an opaque octet string. This attribute MUST be 2121 included in the PAC-Info attribute. The A-ID MUST match the 2122 Authority-ID the server used to establish the tunnel. One 2123 method for generating the A-ID is to use a high-quality 2124 random number generator to generate a random number. An 2125 alternate method would be to take the hash of the public key 2126 or public key certificate belonging a server represented by 2127 the A-ID. 2129 5 - I-ID 2131 Initiator identifier (I-ID) is the peer identity associated 2132 with the credential. This identity is derived from the 2133 inner authentication or from the client-side authentication 2134 during tunnel establishment if inner authentication is not 2135 used. The server employs the I-ID in the TEAP phase 2 2136 conversation to validate that the same peer identity used to 2137 execute TEAP phase 1 is also used in at minimum one inner 2138 authentication in TEAP phase 2. If the server is enforcing 2139 the I-ID validation on the inner authentication, then the 2140 I-ID MUST be included in the PAC-Info, to enable the peer to 2141 also enforce a unique PAC for each unique user. If the I-ID 2142 is missing from the PAC-Info, it is assumed that the Tunnel 2143 PAC can be used for multiple users and the peer will not 2144 enforce the unique-Tunnel-PAC-per-user policy. 2146 7 - A-ID-Info 2148 Authority Identifier Information is intended to provide a 2149 user-friendly name for the A-ID. It may contain the 2150 enterprise name and server name in a human-readable format. 2151 This TLV serves as an aid to the peer to better inform the 2152 end-user about the A-ID. The name is encoded in UTF-8 2153 [RFC3629] format. This attribute MUST be included in the 2154 PAC-Info. 2156 10 - PAC-type 2158 The PAC-Type is intended to provide the type of PAC. This 2159 attribute SHOULD be included in the PAC-Info. If the PAC- 2160 Type is not present, then it defaults to a Tunnel PAC (Type 2161 1). 2163 4.2.12.5. PAC-Acknowledgement TLV 2165 The PAC-Acknowledgement is used to acknowledge the receipt of the 2166 Tunnel PAC by the peer. The peer includes the PAC-Acknowledgement 2167 TLV in a PAC-TLV sent to the server to indicate the result of the 2168 processing and storing of a newly provisioned Tunnel PAC. This TLV 2169 is only used when Tunnel PAC is provisioned. 2171 0 1 2 3 2172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Type | Length | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Result | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 Type 2181 8 - PAC-Acknowledgement 2183 Length 2185 The length of this field is two octets containing a value of 2. 2187 Result 2188 The resulting value MUST be one of the following: 2190 1 - Success 2191 2 - Failure 2193 4.2.12.6. PAC-Type TLV 2195 The PAC-Type TLV is a TLV intended to specify the PAC type. It is 2196 included in a PAC-TLV sent by the peer to request PAC provisioning 2197 from the server. Its format is described below: 2199 0 1 2 3 2200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | Type | Length | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | PAC Type | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 Type 2209 10 - PAC-Type 2211 Length 2213 2-octet Length field with a value of 2 2215 PAC Type 2217 This 2-octet field defines the type of PAC being requested or 2218 provisioned. The following values are defined: 2220 1 - Tunnel PAC 2222 4.2.13. Crypto-Binding TLV 2224 The Crypto-Binding TLV is used to prove that both the peer and server 2225 participated in the tunnel establishment and sequence of 2226 authentications. It also provides verification of the TEAP type, 2227 version negotiated, outer TLVs exchanged before the TLS tunnel 2228 establishment. 2230 The Crypto-Binding TLV MUST be exchanged and verified before the 2231 final Result TLV exchange, regardless whether there is an inner EAP 2232 method authentication or not. It MUST be included with the 2233 Intermediate-Result TLV to perform Cryptographic Binding after each 2234 successful EAP method in a sequence of EAP methods, before proceeding 2235 with another inner EAP method. 2237 The Crypto-Binding TLV is valid only if the following checks pass: 2239 o The Crypto-Binding TLV version is supported 2241 o The MAC verifies correctly 2243 o The received version in the Crypto-Binding TLV matches the version 2244 sent by the receiver during the EAP version negotiation 2246 o The subtype is set to the correct value 2248 If any of the above checks fails, then the TLV is invalid. An 2249 invalid Crypto-Binding TLV is a fatal error and is handled as 2250 described in Section 3.6.3 2252 The Crypto-Binding TLV is defined as follows: 2254 0 1 2 3 2255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 |M|R| TLV Type | Length | 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | Reserved | Version | Received Ver.| Flags|Sub-Type| 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | | 2262 ~ Nonce ~ 2263 | | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | | 2266 ~ EMSK Compound MAC ~ 2267 | | 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | | 2270 ~ MSK Compound MAC ~ 2271 | | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 M 2275 Mandatory, set to one (1) 2277 R 2279 Reserved, set to zero (0) 2281 TLV Type 2283 12 for Crypto-Binding TLV 2285 Length 2287 56 2289 Reserved 2291 Reserved, set to zero (0) 2293 Version 2295 The Version field is a single octet, which is set to the 2296 version of Crypto-Binding TLV the TEAP method is using. For an 2297 implementation compliant with this version of TEAP, the version 2298 number MUST be set to one (1). 2300 Received Version 2302 The Received Version field is a single octet and MUST be set to 2303 the TEAP version number received during version negotiation. 2304 Note that this field only provides protection against downgrade 2305 attacks, where a version of EAP requiring support for this TLV 2306 is required on both sides. 2308 Flags 2310 The Flags field is four bits. Defined values include 2312 1 EMSK Compound MAC is present 2313 2 MSK Compound MAC is present 2315 3 Both EMSK and MSK Compound MAC are present 2317 Sub-Type 2319 The Sub-Type field is four bits. Defined values include 2321 0 Binding Request 2323 1 Binding Response 2325 Nonce 2327 The Nonce field is 32 octets. It contains a 256-bit nonce that 2328 is temporally unique, used for compound MAC key derivation at 2329 each end. The nonce in a request MUST have its least 2330 significant bit set to zero (0) and the nonce in a response 2331 MUST have the same value as the request nonce except the least 2332 significant bit MUST be set to one (1). 2334 EMSK Compound MAC 2336 The EMSK Compound MAC field is 20 octets. This can be the 2337 Server MAC (B1_MAC) or the Client MAC (B2_MAC). The 2338 computation of the MAC is described in Section 5.3. 2340 MSK Compound MAC 2342 The MSK Compound MAC field is 20 octets. This can be the 2343 Server MAC (B1_MAC) or the Client MAC (B2_MAC). The 2344 computation of the MAC is described in Section 5.3. 2346 4.2.14. Basic-Password-Auth-Req TLV 2348 The Basic-Password-Auth-Req TLV is used by the authentication server 2349 to request a username and password from the peer. It contains an 2350 optional user prompt message for the request. The peer is expected 2351 to obtain the username and password and send them in a Basic- 2352 Password-Auth-Resp TLV. 2354 The Basic-Password-Auth-Req TLV is defined as follows: 2356 0 1 2 3 2357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 |M|R| TLV Type | Length | 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 | Prompt .... 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 M 2366 0 (Optional) 2368 R 2370 Reserved, set to zero (0) 2372 TLV Type 2374 13 for Basic-Password-Auth-Req TLV 2376 Length 2378 variable 2380 Prompt 2382 optional user prompt message in UTF-8 [RFC3629] format 2384 4.2.15. Basic-Password-Auth-Resp TLV 2386 The Basic-Password-Auth-Resp TLV is used by the peer to respond to a 2387 Basic-Password-Auth-Req TLV with a username and password. The TLV 2388 contains a username and password. The username and password are in 2389 UTF-8 [RFC3629] format. 2391 The Basic-Password-Auth-Resp TLV is defined as follows: 2393 0 1 2 3 2394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 |M|R| TLV Type | Length | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | Userlen | Username 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 ... Username ... 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | Passlen | Password 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 ... Password ... 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 M 2409 0 (Optional) 2411 R 2413 Reserved, set to zero (0) 2415 TLV Type 2417 14 for Basic-Password-Auth-Resp TLV 2419 Length 2421 variable 2423 Userlen 2425 Length of Username field in octets 2427 Username 2429 Username in UTF-8 [RFC3629] format 2431 Passlen 2432 Length of Password field in octets 2434 Password 2436 Password in UTF-8 [RFC3629] format 2438 4.2.16. PKCS#7 TLV 2440 The PKCS#7 TLV is used by the EAP server to deliver (a) 2441 certificate(s) to the peer. The format consists of a certificate or 2442 certificate chain in binary DER encoding [X.690] in a degenerate 2443 certificates-only PKCS#7 SignedData Content as defined in [RFC5652]. 2445 When used in response to a Trusted-Server-Root TLV request from the 2446 peer, the EAP server MUST send the PKCS#7 TLV inside a Trusted- 2447 Server-Root TLV. When used in response to a PKCS#10 certificate 2448 enrollment request from the peer, the EAP server MUST send the PKCS#7 2449 TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always 2450 marked as optional, which cannot be responded to with a NAK TLV. 2451 TEAP implementations that support the Trusted-Server-Root TLV or the 2452 PKCS#10 TLV MUST support this TLV. Peers MUST NOT assume that the 2453 certificates in a PKCS#7 TLV are in any order. 2455 TEAP Servers MAY return self-signed certificates. Peers that handle 2456 self-signed certificates or trust anchors MUST NOT implicitly trust 2457 these certificates merely due to their presence in the certificate 2458 bag. Note: Peers are advised to take great care in deciding whether 2459 to use a received certificate as a trust anchor. The authenticated 2460 nature of the tunnel in which a PKCS#7 bag is received can provide a 2461 level of authenticity to the certificates contained therein. Peers 2462 are advised to take into account the implied authority of the EAP 2463 server and to constrain the trust it can achieve through the trust 2464 anchor received in a PKCS#7 TLV. 2466 The PKCS#7 TLV is defined as follows: 2468 0 1 2 3 2469 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 |M|R| TLV Type | Length | 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | PKCS #7 Data... 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2475 M 2477 0 - Optional TLV 2479 R 2481 Reserved, set to zero (0) 2483 TLV Type 2485 15 - PKCS#7 TLV 2487 Length 2489 The length of the PKCS #7 Data field. 2491 PKCS #7 Data 2493 This field contains the DER-encoded X.509 certificate or 2494 certificate chain in a Certificates-Only PKCS#7 SignedData 2495 message. 2497 4.2.17. PKCS#10 TLV 2499 The PKCS#10 TLV is used by the peer to initiate the "simple PKI" 2500 Request/Response from [RFC5272]. The format of the request is as 2501 specified in Section 6.4 of [RFC4945]. The PKCS#10 TLV is always 2502 marked as optional, which cannot be responded to with a NAK TLV. 2504 The PKCS#10 TLV is defined as follows: 2506 0 1 2 3 2507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 |M|R| TLV Type | Length | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | PKCS #10 Data... 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2514 M 2516 0 - Optional TLV 2518 R 2520 Reserved, set to zero (0) 2522 TLV Type 2524 16 - PKCS#10 TLV 2526 Length 2528 The length of the PKCS #10 Data field. 2530 PKCS #10 Data 2532 This field contains the DER-encoded PKCS#10 certificate 2533 request. 2535 4.2.18. Trusted-Server-Root TLV 2537 Trusted-Server-Root TLV facilitates the request and delivery of a 2538 trusted server root certificate. The Trusted-Server-Root TLV can be 2539 exchanged in regular TEAP authentication mode or provisioning mode. 2540 The Trusted-Server-Root TLV is always marked as optional, and cannot 2541 be responded to with a Negative Acknowledgement (NAK) TLV. The 2542 Trusted-Server-Root TLV MUST only be sent as an inner TLV (inside the 2543 protection of the tunnel). 2545 After the peer has determined that it has successfully authenticated 2546 the EAP server and validated the Crypto-Binding TLV, it MAY send one 2547 or more Trusted-Server-Root TLVs (marked as optional) to request the 2548 trusted server root certificates from the EAP server. The EAP server 2549 MAY send one or more root certificates with a Public Key 2550 Cryptographic System #7 (PKCS#7) TLV inside Server-Trusted-Root TLV. 2551 The EAP server MAY also choose not to honor the request. 2553 The Trusted-Server-Root TLV allows the peer to send a request to the 2554 EAP server for a list of trusted roots. The server may respond with 2555 one or more root certificates in PKCS#7 [RFC2315] format. 2557 If the EAP server sets the credential format to PKCS#7-Server- 2558 Certificate-Root, then the Trusted-Server-Root TLV should contain the 2559 root of the certificate chain of the certificate issued to the EAP 2560 server packaged in a PKCS#7 TLV. If the Server certificate is a 2561 self-signed certificate, then the root is the self-signed 2562 certificate. 2564 If the Trusted-Server-Root TLV credential format contains a value 2565 unknown to the peer, then the EAP peer should ignore the TLV. 2567 The Trusted-Server-Root TLV is defined as follows: 2569 0 1 2 3 2570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 |M|R| TLV Type | Length | 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 | Credential-Format | Cred TLVs... 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2577 M 2579 0 - Optional TLV 2581 R 2583 Reserved, set to zero (0) 2585 TLV Type 2587 17 - Trusted-Server-Root TLV 2589 Length 2591 >=2 octets 2593 Credential-Format 2595 The Credential-Format field is two octets. Values include: 2597 1 - PKCS#7-Server-Certificate-Root 2599 Cred TLVs 2601 This field is of indefinite length. It contains TLVs 2602 associated with the credential format. The peer may leave 2603 this field empty when using this TLV to request server trust 2604 roots. 2606 4.3. TLV Rules 2608 To save round trips, multiple TLVs can be sent in the single TEAP 2609 packet. However, multiple EAP Payload TLVs, or multiple Basic 2610 Password Authentication TLVs, or an EAP Payload TLV with a Basic 2611 Password Authentication TLV within one single TEAP packet, is not 2612 supported in this version and MUST NOT be sent. If the peer or EAP 2613 server receives multiple EAP Payload TLVs, then it MUST terminate the 2614 connection with the Result TLV. The order of TLVs in TEAP does not 2615 matter, except one should always process the Identity-Type TLV before 2616 processing the EAP TLV or Basic Password Authentication TLV as the 2617 Identity-Type TLV is a hint to the type of identity that is to be 2618 authenticated. 2620 The following table defines the meaning of the table entries in the 2621 sections below: 2623 0 This TLV MUST NOT be present in the message. 2625 0+ Zero or more instances of this TLV MAY be present in the message. 2627 0-1 Zero or one instance of this TLV MAY be present in the message. 2629 1 Exactly one instance of this TLV MUST be present in the message. 2631 4.3.1. Outer TLVs 2633 The following table provides a guide to which TLVs may be included in 2634 the TEAP packet outside the TLS channel, which kind of packets, and 2635 in what quantity: 2637 Request Response Success Failure TLVs 2638 0-1 0 0 0 Authority-ID 2639 0-1 0-1 0 0 Identity-Type 2640 0+ 0+ 0 0 Vendor-Specific 2642 Outer-TLVs MUST be marked as optional. Vendor-TLVs inside Vendor- 2643 Specific TLV MUST be marked as optional when included in Outer TLVs. 2644 Outer-TLVs MUST NOT be included in messages after the first two TEAP 2645 messages sent by peer and EAP-server respectively. That is the first 2646 EAP server to peer message and first peer to EAP server message. If 2647 the message is fragmented, the whole set of messages is counted as 2648 one message. If Outer-TLVs are included in messages after the first 2649 two TEAP messages, they MUST be ignored. 2651 4.3.2. Inner TLVs 2653 The following table provides a guide to which inner TLVs may be 2654 encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in 2655 what quantity. The messages are as follows: Request is a TEAP 2656 Request, Response is a TEAP Response, Success is a message containing 2657 a successful Result TLV, and Failure is a message containing a failed 2658 Result TLV. 2660 Request Response Success Failure TLVs 2661 0-1 0-1 0 0 Identity-Type 2662 0-1 0-1 1 1 Result 2663 0+ 0+ 0 0 NAK 2664 0+ 0+ 0+ 0+ Error 2665 0-1 0-1 0 0 Channel-Binding 2666 0+ 0+ 0+ 0+ Vendor-Specific [NOTE1] 2667 0+ 0+ 0+ 0+ Request-Action 2668 0-1 0-1 0 0 EAP-Payload 2669 0-1 0-1 0-1 0-1 Intermediate-Result 2670 0+ 0+ 0+ 0 PAC-TLV 2671 0-1 0-1 0-1 0-1 Crypto-Binding 2672 0-1 0 0 0 Basic-Password-Auth-Req 2673 0 0-1 0 0 Basic-Password-Auth-Resp 2674 0-1 0 0-1 0 PKCS#7 2675 0 0-1 0 0 PKCS#10 2676 0-1 0-1 0-1 0 Server-Trusted-Root 2678 [NOTE1] Vendor TLVs (included in Vendor-Specific TLVs) sent with a 2679 Result TLV MUST be marked as optional. 2681 5. Cryptographic Calculations 2683 For key derivation and crypto-binding, TEAP uses the PRF and MAC 2684 algorithms negotiated in the underlying TLS session. Since these 2685 algorithms depend on the TLS version and cipher suite, TEAP 2686 implementations need a mechanism to determine the version and cipher 2687 suite in use for a particular session. The implementation can then 2688 use this information to determine which PRF and MAC algorithm to use. 2690 5.1. TEAP Authentication Phase 1: Key Derivations 2692 With TEAPv1, the TLS master secret is generated as specified in TLS. 2693 If a PAC is used then the master secret is obtained as described in 2694 [RFC5077]. 2696 TEAPv1 makes use of the TLS Keying Material Exporters defined in 2697 [RFC5705] to derive the session_key_seed. The Label used in the 2698 derivation is "EXPORTER: teap session key seed". The length of the 2699 session key seed material is 40 octets. No context data is used in 2700 the export process. 2702 The session_key_seed is used by the TEAP Authentication Phase 2 2703 conversation to both cryptographically bind the inner method(s) to 2704 the tunnel as well as generate the resulting TEAP session keys. The 2705 other quantities are used as they are defined in [RFC5246]. 2707 5.2. Intermediate Compound Key Derivations 2709 The session_key_seed derived as part of TEAP Phase 2 is used in TEAP 2710 Phase 2 to generate an Intermediate Compound Key (IMCK) used to 2711 verify the integrity of the TLS tunnel after each successful inner 2712 authentication and in the generation of Master Session Key (MSK) and 2713 Extended Master Session Key (EMSK) defined in [RFC3748]. Note that 2714 the IMCK MUST be recalculated after each successful inner EAP method. 2716 The first step in these calculations is the generation of the base 2717 compound key, IMCK[n] from the session_key_seed and any session keys 2718 derived from the successful execution of nth inner EAP methods. The 2719 inner EAP method(s) may provide Inner Method Session Keys (IMSK), 2720 IMSK1..IMSKn, corresponding to inner method 1 through n. 2722 If an inner method supports export of an Extended Master Session Key 2723 (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in 2724 [RFC5295]. The usage label used is "TEAPbindkey@ietf.org" and the 2725 length is 64 octets. Optional data parameter is not used in the 2726 derivation. 2728 IMSK = First 32 octets of KDF(EMSK, "TEAPbindkey@ietf.org" | "\0" | 2729 64) 2731 where "|" denotes concatenation, "EMSK" consists of the 4 ASCII 2732 values for the letters, "\0" = is a NULL octet (0x00 in hex), 2733 length is the 2-octet unsigned integer in network byte order, KDF 2734 is defined in [RFC5295]. 2736 If an inner method does not support export of an Extended Master 2737 Session Key (EMSK), then IMSK is the MSK of the inner method. The 2738 MSK is truncated at 32 octets if it is longer than 32 octets or 2739 padded to a length of 32 octets with zeros if it is less than 32 2740 octets. 2742 However, it's possible that the peer and server sides might not have 2743 the same capability to export EMSK. In order to maintain maximum 2744 flexibility while prevent downgrading attack, the following mechanism 2745 is in place: 2747 On the sender of the Crypto-Binding TLV side: 2749 If the EMSK is not available, then computes the Compound MAC using 2750 MSK of the inner method. 2752 If the EMSK is available, and the sender's policy accepts MSK based 2753 MAC, then it computes two Compound MAC values. The first is 2754 computed with the EMSK. The second one is computed using the MSK. 2755 Both MACs are then sent to the other side. 2757 If the EMSK is available, but the sender's policy does not allow 2758 downgrade to MSK generated MAC, then it SHOULD only send EMSK based 2759 MAC. 2761 On the receiver of the Crypto-Binding TLV side: 2763 If the EMSK is not available and a MSK based Compound MAC was sent, 2764 validates the Compound MAC and sends back a MSK based Compound MAC 2765 response. 2767 If the EMSK is not available and no MSK based Compound MAC was 2768 sent, then handles like an invalid Crypto-Binding TLV with fatal 2769 error. 2771 If the EMSK is available and an EMSK based Compound MAC was sent, 2772 validates it and creates a response Compound MAC using the EMSK. 2774 If the EMSK is available, but no EMSK based Compound MAC was sent, 2775 and its policy accepts MSK based MAC, then validates it using the 2776 MSK and if successful, generates and returns a MSK based Compound 2777 MAC. 2779 If the EMSK is available, but no EMSK Compound MAC was sent, and 2780 its policy does not accept MSK based MAC, then it handles like an 2781 invalid Crypto-Binding TLV with fatal error. 2783 If the ith inner method does not generate an EMSK or MSK, then IMSKi 2784 is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method 2785 fails, then it is not included in this calculation. The derivations 2786 of S-IMCK is as follows: 2788 S-IMCK[0] = session_key_seed 2789 For j = 1 to n-1 do 2790 IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", 2791 IMSK[j], 60) 2792 S-IMCK[j] = first 40 octets of IMCK[j] 2793 CMK[j] = last 20 octets of IMCK[j] 2795 where TLS-PRF is the PRF negotiated as part of TLS handshake 2796 [RFC5246]. 2798 5.3. Computing the Compound MAC 2800 For authentication methods that generate keying material, further 2801 protection against man-in-the-middle attacks is provided through 2802 cryptographically binding keying material established by both TEAP 2803 Phase 1 and TEAP Phase 2 conversations. After each successful inner 2804 EAP authentication, EAP EMSK and/or MSKs are cryptographically 2805 combined with key material from TEAP Phase 1 to generate a compound 2806 session key, CMK. The CMK is used to calculate the Compound MAC as 2807 part of the Crypto-Binding TLV described in Section 4.2.13, which 2808 helps provide assurance that the same entities are involved in all 2809 communications in TEAP. During the calculation of the Compound-MAC 2810 the MAC field is filled with zeros. 2812 The Compound MAC computation is as follows: 2814 CMK = CMK[j] 2815 Compound-MAC = MAC( CMK, BUFFER ) 2817 where j is the number of the last successfully executed inner EAP 2818 method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and 2819 BUFFER is created after concatenating these fields in the following 2820 order: 2822 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK 2823 Compound MAC fields zeroed out. 2825 2 The EAP Type sent by the other party in the first TEAP message. 2827 3 All the Outer-TLVs from the first TEAP message sent by EAP server 2828 to peer. If a single TEAP message is fragmented into multiple 2829 TEAP packets; then the Outer-TLVs in all the fragments of that 2830 message MUST be included. 2832 4 All the Outer-TLVs from the first TEAP message sent by the peer to 2833 the EAP server. If a single TEAP message is fragmented into 2834 multiple TEAP packets, then the Outer-TLVs in all the fragments of 2835 that message MUST be included. 2837 5.4. EAP Master Session Key Generation 2838 TEAP Authentication assures the master session key (MSK) and Extended 2839 Master Session Key (EMSK) output from the EAP method are the result 2840 of all authentication conversations by generating an Intermediate 2841 Compound Key (IMCK). The IMCK is mutually derived by the peer and 2842 the server as described in Section 5.2 by combining the MSKs from 2843 inner EAP methods with key material from TEAP Phase 1. The resulting 2844 MSK and EMSK are generated as part of the IMCKn key hierarchy as 2845 follows: 2847 MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) 2848 EMSK = TLS-PRF(S-IMCK[j], 2849 "Extended Session Key Generating Function", 64) 2851 where j is the number of the last successfully executed inner EAP 2852 method. 2854 The EMSK is typically only known to the TEAP peer and server and is 2855 not provided to a third party. The derivation of additional keys and 2856 transportation of these keys to a third party is outside the scope of 2857 this document. 2859 If no EAP methods have been negotiated inside the tunnel or no EAP 2860 methods have been successfully completed inside the tunnel, the MSK 2861 and EMSK will be generated directly from the session_key_seed meaning 2862 S-IMCK = session_key_seed. 2864 6. IANA Considerations 2866 This section provides guidance to the Internet Assigned Numbers 2867 Authority (IANA) regarding registration of values related to the TEAP 2868 protocol, in accordance with BCP 26, [RFC5226]. 2870 The EAP Method Type number for TEAP needs to be assigned. 2872 The document defines a registry for TEAP TLV types, which may be 2873 assigned by Specification Required as defined in [RFC5226]. 2874 Section 4.2 defines the TLV types that initially populate the 2875 registry. A summary of the TEAP TLV types is given below: 2877 0 Unassigned 2879 1 Authority-ID TLV 2881 2 Identity-Type TLV 2882 3 Result TLV 2884 4 NAK TLV 2886 5 Error TLV 2888 6 Channel-Binding TLV 2890 7 Vendor-Specific TLV 2892 8 Request-Action TLV 2894 9 EAP-Payload TLV 2896 10 Intermediate-Result TLV 2898 11 PAC TLV 2900 12 Crypto-Binding TLV 2902 13 Basic-Password-Auth-Req TLV 2904 14 Basic-Password-Auth-Resp TLV 2906 15 PKCS#7 TLV 2908 16 PKCS#10 TLV 2910 17 Trusted-Server-Root TLV 2912 The Identity-Type defined in Section 4.2.3 contains an Identity Type 2913 code which is assigned on a Specification Required basis as defined 2914 in [RFC5226]. The initial types defined are: 2916 1 User 2918 2 Machine 2920 The Result TLV defined in Section 4.2.4, Request-Action TLV defined 2921 in Section 4.2.9, and Intermediate-Result TLV defined in 2922 Section 4.2.11 contain a Status code which is assigned on a 2923 Specification Required basis as defined in [RFC5226]. The initial 2924 types defined are: 2926 1 Success 2928 2 Failure 2929 The Error-TLV defined in Section 4.2.6 requires an error-code. TEAP 2930 Error-TLV error-codes are assigned based on Specification Required as 2931 defined in [RFC5226]. The initial list of error codes is as follows: 2933 1 User account expires soon 2935 2 User account credential expires soon 2937 3 User account authorisations change soon 2939 4 Clock skew detected 2941 5 Contact administrator 2943 6 User account credentials change required 2945 1001 Inner Method Error 2947 1002 Unspecified authentication infrastructure problem 2949 1003 Unspecified authentication failure 2951 1004 Unspecified authorisation failure 2953 1005 User account credentials unavailable 2955 1006 User account expired 2957 1007 User account locked: try again later 2959 1008 User account locked: admin intervention required 2961 1009 Authentication infrastructure unavailable 2963 1010 Authentication infrastructure not trusted 2965 1011 Clock skew too great 2967 1012 Invalid inner realm 2969 1013 Token out of sync: administrator intervention required 2971 1014 Token out of sync: PIN change required 2973 1015 Token revoked 2975 1016 Tokens exhausted 2976 1017 Challenge expired 2978 1018 Challenge algorithm mismatch 2980 1019 Client certificate not supplied 2982 1020 Client certificate rejected 2984 1021 Realm mismatch between inner and outer identity 2986 1022 Unsupported Algorithm In Certificate Signing Request 2988 1023 Unsupported Extension In Certificate Signing Request 2990 1024 Bad Identity In Certificate Signing Request 2992 1025 Bad Certificate Signing Request 2994 1026 Internal CA Error 2996 1027 General PKI Error 2998 1028 Inner method's channel binding data required but not supplied 3000 1029 Inner method's channel binding data did not include required 3001 information 3003 1030 Inner method's channel binding failed 3005 1031 User account credentials incorrect [USAGE NOT RECOMMENDED] 3007 2001 Tunnel Compromise Error 3009 2002 Unexpected TLVs Exchanged 3011 The Request-Action TLV defined in Section 4.2.9 contains an action 3012 code which is assigned on a Specification Required basis as defined 3013 in [RFC5226]. The initial actions defined are: 3015 1 Process-TLV 3017 2 Negotiate-EAP 3019 The PAC Attribute defined in Section 4.2.12.1 contains a Type code 3020 which is assigned on a Specification Required basis as defined in 3021 [RFC5226]. The initial types defined are: 3023 1 PAC-key 3025 2 PAC-Opaque 3027 3 PAC-Lifetime 3029 4 A-ID 3031 5 I-ID 3033 6 Reserved 3035 7 A-ID-Info 3037 8 PAC-Acknowledgement 3039 9 PAC-Info 3041 10 PAC-Type 3043 The PAC-Type defined in Section 4.2.12.6 contains a Type code which 3044 is assigned on a Specification Required basis as defined in 3045 [RFC5226]. The initial types defined are: 3047 1 Tunnel PAC 3049 The Trusted-Server-Root TLV defined in Section 4.2.18 contains a 3050 Credential-Format code which is assigned on a Specification Required 3051 basis as defined in [RFC5226]. The initial types defined are: 3053 1 PKCS#7-Server-Certificate-Root 3055 The various values under Vendor-Specific TLV are assigned by Private 3056 Use and do not need to be assigned by IANA. 3058 TEAP registers the label "EXPORTER: teap session key seed" in the TLS 3059 Exporter Label Registry [RFC5705]. This label is used in derivation 3060 as defined in Section 5.1. 3062 TEAP registers a TEAP binding usage label from the "USRK Key Labels" 3063 name space defined in [RFC5295] with a value "TEAPbindkey@ietf.org". 3065 7. Security Considerations 3067 TEAP is designed with a focus on wireless media, where the medium 3068 itself is inherent to eavesdropping. Whereas in wired media, an 3069 attacker would have to gain physical access to the wired medium; 3070 wireless media enables anyone to capture information as it is 3071 transmitted over the air, enabling passive attacks. Thus, physical 3072 security can not be assumed and security vulnerabilities are far 3073 greater. The threat model used for the security evaluation of TEAP 3074 is defined in EAP [RFC3748]. 3076 7.1. Mutual Authentication and Integrity Protection 3078 TEAP as a whole, provides message and integrity protection by 3079 establishing a secure tunnel for protecting the authentication 3080 method(s). The confidentiality and integrity protection is defined 3081 by TLS and provides the same security strengths afforded by TLS 3082 employing a strong entropy shared master secret. The integrity of 3083 the key generating authentication methods executed within the TEAP 3084 tunnel is verified through the calculation of the Crypto-Binding TLV. 3085 This ensures that the tunnel endpoints are the same as the inner 3086 method endpoints. 3088 The Result TLV is protected and conveys the true Success or Failure 3089 of TEAP, and should be used as the indicator of its success or 3090 failure respectively. However, as EAP terminates with either a clear 3091 text EAP Success or Failure, a peer will also receive a clear text 3092 EAP Success or Failure. The received clear text EAP Success or 3093 Failure MUST match that received in the Result TLV; the peer SHOULD 3094 silently discard those clear text EAP success or failure messages 3095 that do not coincide with the status sent in the protected Result 3096 TLV. 3098 7.2. Method Negotiation 3100 As is true for any negotiated EAP protocol, NAK packets used to 3101 suggest an alternate authentication method are sent unprotected and 3102 as such, are subject to spoofing. During unprotected EAP method 3103 negotiation, NAK packets may be interjected as active attacks to 3104 negotiate down to a weaker form of authentication, such as EAP-MD5 3105 (which only provides one-way authentication and does not derive a 3106 key). Both the peer and server should have a method selection policy 3107 that prevents them from negotiating down to weaker methods. Inner 3108 method negotiation resists attacks because it is protected by the 3109 mutually authenticated TLS tunnel established. Selection of TEAP as 3110 an authentication method does not limit the potential inner 3111 authentication methods, so TEAP should be selected when available. 3113 An attacker cannot readily determine the inner EAP method used, 3114 except perhaps by traffic analysis. It is also important that peer 3115 implementations limit the use of credentials with an unauthenticated 3116 or unauthorized server. 3118 7.3. Separation of Phase 1 and Phase 2 Servers 3120 Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT 3121 RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a 3122 different server than the Phase 2 conversation can introduce 3123 vulnerabilities if there is not a proper trust relationship and 3124 protection for the protocol between the two servers. Some 3125 vulnerabilities include: 3127 o Loss of identity protection 3129 o Offline dictionary attacks 3131 o Lack of policy enforcement 3133 o Man-in-the-middle attacks (as described in [RFC7029]) 3135 There may be cases where a trust relationship exists between the 3136 Phase 1 and Phase 2 servers, such as on a campus or between two 3137 offices within the same company, where there is no danger in 3138 revealing the inner identity and credentials of the peer to entities 3139 between the two servers. In these cases, using a proxy solution 3140 without end-to-end protection of TEAP MAY be used. The TEAP 3141 encrypting/decrypting gateway MUST, at a minimum, provide support for 3142 IPsec, TLS or similar protection in order to provide confidentiality 3143 for the portion of the conversation between the gateway and the EAP 3144 server. In addition, separation of the inner and outer method 3145 servers allows for crypto-binding based on the inner method MSK to be 3146 thwarted as described in [RFC7029]. Implementation and deployment 3147 SHOULD adopt various mitigation strategies described in [RFC7029]. 3148 If the inner method is deriving EMSK, then this threat is mitigated 3149 as TEAP utilizes the mutual crypto-binding based on EMSK as described 3150 in [RFC7029]. 3152 7.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies 3154 TEAP addresses the known deficiencies and weaknesses in the EAP 3155 method. By employing a shared secret between the peer and server to 3156 establish a secured tunnel, TEAP enables: 3158 o Per packet confidentiality and integrity protection 3160 o User identity protection 3162 o Better support for notification messages 3164 o Protected EAP inner method negotiation 3165 o Sequencing of EAP methods 3167 o Strong mutually derived master session keys 3169 o Acknowledged success/failure indication 3171 o Faster re-authentications through session resumption 3173 o Mitigation of dictionary attacks 3175 o Mitigation of man-in-the-middle attacks 3177 o Mitigation of some denial-of-service attacks 3179 It should be noted that TEAP, as in many other authentication 3180 protocols, a denial-of-service attack can be mounted by adversaries 3181 sending erroneous traffic to disrupt the protocol. This is a problem 3182 in many authentication or key agreement protocols and is therefore 3183 noted for TEAP as well. 3185 TEAP was designed with a focus on protected authentication methods 3186 that typically rely on weak credentials, such as password-based 3187 secrets. To that extent, the TEAP Authentication mitigates several 3188 vulnerabilities, such as dictionary attacks, by protecting the weak 3189 credential-based authentication method. The protection is based on 3190 strong cryptographic algorithms in TLS to provide message 3191 confidentiality and integrity. The keys derived for the protection 3192 relies on strong random challenges provided by both peer and server 3193 as well as an established key with strong entropy. Implementations 3194 should follow the recommendation in [RFC4086] when generating random 3195 numbers. 3197 7.4.1. User Identity Protection and Verification 3199 The initial identity request response exchange is sent in cleartext 3200 outside the protection of TEAP. Typically the Network Access 3201 Identifier (NAI) [RFC4282] in the identity response is useful only 3202 for the realm information that is used to route the authentication 3203 requests to the right EAP server. This means that the identity 3204 response may contain an anonymous identity and just contain realm 3205 information. In other cases, the identity exchange may be eliminated 3206 altogether if there are other means for establishing the destination 3207 realm of the request. In no case should an intermediary place any 3208 trust in the identity information in the identity response since it 3209 is unauthenticated and may not have any relevance to the 3210 authenticated identity. TEAP implementations should not attempt to 3211 compare any identity disclosed in the initial cleartext EAP Identity 3212 response packet with those Identities authenticated in Phase 2. 3214 Identity request-response exchanges sent after the TEAP tunnel is 3215 established are protected from modification and eavesdropping by 3216 attackers. 3218 Note that since TLS client certificates are sent in the clear, if 3219 identity protection is required, then it is possible for the TLS 3220 authentication to be re-negotiated after the first server 3221 authentication. To accomplish this, the server will typically not 3222 request a certificate in the server_hello, then after the 3223 server_finished message is sent, and before TEAP Phase 2, the server 3224 MAY send a TLS hello_request. This allows the peer to perform client 3225 authentication by sending a client_hello if it wants to, or send a 3226 no_renegotiation alert to the server indicating that it wants to 3227 continue with TEAP Phase 2 instead. Assuming that the peer permits 3228 renegotiation by sending a client_hello, then the server will respond 3229 with server_hello, a certificate and certificate_request messages. 3230 The peer replies with certificate, client_key_exchange and 3231 certificate_verify messages. Since this re-negotiation occurs within 3232 the encrypted TLS channel, it does not reveal client certificate 3233 details. It is possible to perform certificate authentication using 3234 an EAP method (for example: EAP-TLS) within the TLS session in TEAP 3235 Phase 2 instead of using TLS handshake renegotiation. 3237 7.4.2. Dictionary Attack Resistance 3239 TEAP was designed with a focus on protected authentication methods 3240 that typically rely on weak credentials, such as password-based 3241 secrets. TEAP mitigates dictionary attacks by allowing the 3242 establishment of a mutually authenticated encrypted TLS tunnel 3243 providing confidentiality and integrity to protect the weak 3244 credential based authentication method. 3246 7.4.3. Protection against Man-in-the-Middle Attacks 3248 Allowing methods to be executed both with and without the protection 3249 of a secure tunnel opens up a possibility of a man-in-the-middle 3250 attack. To avoid man-in-the-middle attacks it is recommended to 3251 always deploy authentication methods with protection of TEAP. TEAP 3252 provides protection from man-in-the-middle attacks even if a 3253 deployment chooses to execute inner EAP methods both with and without 3254 TEAP protection, TEAP prevents this attack in two ways: 3256 1. By using the PAC-Key to mutually authenticate the peer and server 3257 during TEAP Authentication Phase 1 establishment of a secure 3258 tunnel. 3260 2. By using the keys generated by the inner authentication method 3261 (if the inner methods are key generating) in the crypto-binding 3262 exchange and in the generation of the key material exported by 3263 the EAP method described in Section 5. 3265 TEAP crypto binding does not guarantee man-in-the-middle protection 3266 if the client does not validate the server's certificate. If the TLS 3267 cipher suite derives the master secret solely from the contribution 3268 of secret data from one side of the conversation (such as RSA key 3269 transport based ciphersuites) then an attacker can insert themselves 3270 in the conversation if the server certificate is not verified even if 3271 a strong inner method is executed within the tunnel. If the TLS 3272 ciphersuite derives the master secret from the contribution of 3273 secrets from both sides of the conversation (such as in Diffie- 3274 Hellman based cipher suites) then crypto binding can detect an 3275 attacker in the conversation if a strong inner method is used. 3277 7.4.4. PAC Binding to User Identity 3279 A PAC may be bound to a user identity. A compliant implementation of 3280 TEAP MUST validate that an identity obtained in the PAC-Opaque field 3281 matches at minimum one of the identities provided in the TEAP Phase 2 3282 authentication method. This validation provides another binding to 3283 ensure that the intended peer (based on identity) has successfully 3284 completed the TEAP Phase 1 and proved identity in the Phase 2 3285 conversations. 3287 7.5. Protecting against Forged Clear Text EAP Packets 3289 EAP Success and EAP Failure packets are, in general, sent in clear 3290 text and may be forged by an attacker without detection. Forged EAP 3291 Failure packets can be used to attempt to convince an EAP peer to 3292 disconnect. Forged EAP Success packets may be used to attempt to 3293 convince a peer that authentication has succeeded, even though the 3294 authenticator has not authenticated itself to the peer. 3296 By providing message confidentiality and integrity, TEAP provides 3297 protection against these attacks. Once the peer and AS initiate the 3298 TEAP Authentication Phase 2, compliant TEAP implementations MUST 3299 silently discard all clear text EAP messages, unless both the TEAP 3300 peer and server have indicated success or failure using a protected 3301 mechanism. Protected mechanisms include TLS alert mechanism and the 3302 protected termination mechanism described in Section 3.3.3. 3304 The success/failure decisions within the TEAP tunnel indicate the 3305 final decision of the TEAP authentication conversation. After a 3306 success/failure result has been indicated by a protected mechanism, 3307 the TEAP peer can process unprotected EAP Success and EAP Failure 3308 messages; however the peer MUST ignore any unprotected EAP success or 3309 failure messages where the result does not match the result of the 3310 protected mechanism. 3312 To abide by [RFC3748], the server sends a clear text EAP Success or 3313 EAP Failure packet to terminate the EAP conversation. However, since 3314 EAP Success and EAP Failure packets are not retransmitted, the final 3315 packet may be lost. While a TEAP protected EAP Success or EAP 3316 Failure packet should not be a final packet in a TEAP conversation, 3317 it may occur based on the conditions stated above, so an EAP peer 3318 should not rely upon the unprotected EAP success and failure 3319 messages. 3321 7.6. Server Certificate Validation 3323 As part of the TLS negotiation, the server presents a certificate to 3324 the peer. The peer SHOULD verify the validity of the EAP server 3325 certificate, and SHOULD also examine the EAP server name presented in 3326 the certificate, in order to determine whether the EAP server can be 3327 trusted. When performing server certificate validation 3328 implementations MUST provide support rules in [RFC5280] for 3329 validating certificates against a known trust anchor. In addition, 3330 implementations MUST support matching the realm portion of the peer's 3331 NAI against a SubjectAltName of type dNSName within the server 3332 certificate. However, in certain deployments, this might not be 3333 turned on. Please note that in the case where the EAP authentication 3334 is remote, the EAP server will not reside on the same machine as the 3335 authenticator, and therefore the name in the EAP server's certificate 3336 cannot be expected to match that of the intended destination. In 3337 this case, a more appropriate test might be whether the EAP server's 3338 certificate is signed by a CA controlling the intended domain and 3339 whether the authenticator can be authorized by a server in that 3340 domain. 3342 7.7. Tunnel PAC Considerations 3344 Since the Tunnel PAC is stored by the peer, special care should be 3345 given to the overall security of the peer. The Tunnel PAC MUST be 3346 securely stored by the peer to prevent theft or forgery of any of the 3347 Tunnel PAC components. In particular, the peer MUST securely store 3348 the PAC-Key and protect it from disclosure or modification. 3349 Disclosure of the PAC-Key enables an attacker to establish the TEAP 3350 tunnel; however, disclosure of the PAC-Key does not reveal the peer 3351 or server identity or compromise any other peer's PAC credentials. 3352 Modification of the PAC-Key or PAC-Opaque components of the Tunnel 3353 PAC may also lead to denial of service as the tunnel establishment 3354 will fail. The PAC-Opaque component is the effective TLS ticket 3355 extension used to establish the tunnel using the techniques of 3356 [RFC5077]. Thus, the security considerations defined by [RFC5077] 3357 also apply to the PAC- Opaque. The PAC-Info may contain information 3358 about the Tunnel PAC such as the identity of the PAC issuer and the 3359 Tunnel PAC lifetime for use in the management of the Tunnel PAC. The 3360 PAC-Info should be securely stored by the peer to protect it from 3361 disclosure and modification. 3363 7.8. Security Claims 3365 This section provides the needed security claim requirement for EAP 3366 [RFC3748]. 3368 Auth. mechanism: Certificate based, shared secret based and 3369 various tunneled authentication mechanisms. 3371 Ciphersuite negotiation: Yes 3373 Mutual authentication: Yes 3375 Integrity protection: Yes, Any method executed within the TEAP 3376 tunnel is integrity protected. The 3377 cleartext EAP headers outside the tunnel are 3378 not integrity protected. 3380 Replay protection: Yes 3382 Confidentiality: Yes 3384 Key derivation: Yes 3386 Key strength: See Note 1 below. 3388 Dictionary attack prot.: Yes 3390 Fast reconnect: Yes 3392 Cryptographic binding: Yes 3394 Session independence: Yes 3396 Fragmentation: Yes 3398 Key Hierarchy: Yes 3400 Channel binding: Yes 3402 Notes 3403 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The 3404 National Institute for Standards and Technology (NIST) also 3405 offers advice on appropriate key sizes in [NIST-SP-800-57]. 3406 [RFC3766] Section 5 advises use of the following required RSA or 3407 DH module and DSA subgroup size in bits, for a given level of 3408 attack resistance in bits. Based on the table below, a 2048-bit 3409 RSA key is required to provide 128-bit equivalent key strength: 3411 Attack Resistance RSA or DH Modulus DSA subgroup 3412 (bits) size (bits) size (bits) 3413 ----------------- ----------------- ------------ 3414 70 947 129 3415 80 1228 148 3416 90 1553 167 3417 100 1926 186 3418 150 4575 284 3419 200 8719 383 3420 250 14596 482 3422 8. Acknowledgements 3424 The TEAP v1 design and protocol specification is based on EAP-FAST 3425 [RFC4851], which included the ideas and hard efforts of Nancy Cam- 3426 Winget, David McGrew, Joe Salowey, Hao Zhou, Pad Jakkahalli, Mark 3427 Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc. 3429 The TLV processing was inspired from work on the Protected Extensible 3430 Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan 3431 Smith, Sean Turner and Simon Josefsson. 3433 Helpful review comments were provided by Russ Housley, Jari Arkko, 3434 Ilan Frenkel, Jeremy Steiglitz, Dan Harkins, Sam Hartman, Jim Schaad, 3435 Barry Leiba, Stephen Farrell, Chris Lonvick and Josh Howlett. 3437 9. References 3439 9.1. Normative References 3441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3442 Requirement Levels", BCP 14, RFC 2119, March 1997. 3444 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3445 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3446 3748, June 2004. 3448 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 3449 "Transport Layer Security (TLS) Session Resumption without 3450 Server-Side State", RFC 5077, January 2008. 3452 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3453 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3454 May 2008. 3456 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3457 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3459 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 3460 "Specification for the Derivation of Root Keys from an 3461 Extended Master Session Key (EMSK)", RFC 5295, August 3462 2008. 3464 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 3465 Layer Security (TLS)", RFC 5705, March 2010. 3467 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 3468 "Transport Layer Security (TLS) Renegotiation Indication 3469 Extension", RFC 5746, February 2010. 3471 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 3472 for TLS", RFC 5929, July 2010. 3474 [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding 3475 Support for Extensible Authentication Protocol (EAP) 3476 Methods", RFC 6677, July 2012. 3478 9.2. Informative References 3480 [IEEE.802-1X.2004] 3481 "Local and Metropolitan Area Networks: Port-Based Network 3482 Access Control", IEEE Standard 802.1X, December 2004. 3484 [NIST-SP-800-57] 3485 National Institute of Standards and Technology, 3486 "Recommendation for Key Management", NIST Special 3487 Publication 800-57, May 2006. 3489 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 3490 Authentication Protocol (PEAP) Specification", August 3491 2009. 3493 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 3494 Version 1.5", RFC 2315, March 1998. 3496 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 3497 Classes and Attribute Types Version 2.0", RFC 2985, 3498 November 2000. 3500 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3501 Request Syntax Specification Version 1.7", RFC 2986, 3502 November 2000. 3504 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 3505 Dial In User Service) Support For Extensible 3506 Authentication Protocol (EAP)", RFC 3579, September 2003. 3508 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3509 10646", STD 63, RFC 3629, November 2003. 3511 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 3512 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 3513 RFC 3766, April 2004. 3515 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 3516 Authentication Protocol (EAP) Application", RFC 4072, 3517 August 2005. 3519 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3520 Requirements for Security", BCP 106, RFC 4086, June 2005. 3522 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 3523 Network Access Identifier", RFC 4282, December 2005. 3525 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3526 Encodings", RFC 4648, October 2006. 3528 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 3529 Flexible Authentication via Secure Tunneling Extensible 3530 Authentication Protocol Method (EAP-FAST)", RFC 4851, May 3531 2007. 3533 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1 3534 /ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 3536 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 3537 Authentication Protocol (EAP) Key Management Framework", 3538 RFC 5247, August 2008. 3540 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 3541 (CMC)", RFC 5272, June 2008. 3543 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3544 Housley, R., and W. Polk, "Internet X.509 Public Key 3545 Infrastructure Certificate and Certificate Revocation List 3546 (CRL) Profile", RFC 5280, May 2008. 3548 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 3549 Protocol Tunneled Transport Layer Security Authenticated 3550 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 3552 [RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange 3553 within the Flexible Authentication via Secure Tunneling 3554 Extensible Authentication Protocol (EAP-FAST)", RFC 5421, 3555 March 2009. 3557 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3558 RFC 5652, September 2009. 3560 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 3561 Protocol (EAP) Authentication Using Only a Password", RFC 3562 5931, August 2010. 3564 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 3565 Extension Definitions", RFC 6066, January 2011. 3567 [RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 3568 EAP Authentication Method Based on the Encrypted Key 3569 Exchange (EKE) Protocol", RFC 6124, February 2011. 3571 [RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, 3572 "Requirements for a Tunnel-Based Extensible Authentication 3573 Protocol (EAP) Method", RFC 6678, July 2012. 3575 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 3576 Galperin, S., and C. Adams, "X.509 Internet Public Key 3577 Infrastructure Online Certificate Status Protocol - OCSP", 3578 RFC 6960, June 2013. 3580 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 3581 Multiple Certificate Status Request Extension", RFC 6961, 3582 June 2013. 3584 [RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible 3585 Authentication Protocol (EAP) Mutual Cryptographic 3586 Binding", RFC 7029, October 2013. 3588 [X.690] ITU-T, "ITU-T Recommendation X.690 ASN.1 encoding rules: 3589 Specification of Basic Encoding Rules (BER), Canonical 3590 Encoding Rules (CER) and Distinguished Encoding Rules 3591 (DER)", ITU-T X.690, November 2008. 3593 Appendix A. Evaluation Against Tunnel Based EAP Method Requirements 3595 This section evaluates all tunnel based EAP method requirements 3596 described in [RFC6678] against TEAP version 1. 3598 A.1. Requirement 4.1.1 RFC Compliance 3600 TEAP v1 meets this requirement by being compliant to RFC 3748, RFC 3601 4017, RFC 5247, and RFC 4962. It is also compliant with the 3602 "cryptographic algorithm agility" requirement by leveraging TLS 1.2 3603 for all cryptographic algorithm negotiation. 3605 A.2. Requirement 4.2.1 TLS Requirements 3607 Requirement 4.2.1 states: 3609 The tunnel based method MUST support TLS version 1.2 [RFC5246] and 3610 may support earlier versions greater than SSL 2.0 to enable the 3611 possibility of backwards compatibility. 3613 TEAP v1 meets this requirement by mandating TLS version 1.2 support 3614 as defined in Section 3.2. 3616 A.3. Requirement 4.2.1.1.1 Cipher Suite Negotiation 3618 Requirement 4.2.1.1.1 states: 3620 Hence, the tunnel method MUST provide integrity protected cipher 3621 suite negotiation with secure integrity algorithms and integrity 3622 keys. 3624 TEAP v1 meets this requirement by using TLS to provide protected 3625 cipher suite negotiation. 3627 A.4. Requirement 4.2.1.1.2 Tunnel Data Protection Algorithms 3629 Requirement 4.2.1.1.2 states: 3631 The tunnel method MUST provide at least one mandatory to implement 3632 cipher suite that provides the equivalent security of 128-bit AES for 3633 encryption and message authentication. 3635 TEAP v1 meets this requirement by mandating 3636 TLS_RSA_WITH_AES_128_CBC_SHA as a mandatory to implement cipher suite 3637 as defined in Section 3.2. 3639 A.5. Requirement 4.2.1.1.3 Tunnel Authentication and Key Establishment 3641 TEAP v1 meets this requirement by mandating 3642 TLS_RSA_WITH_AES_128_CBC_SHA as a mandatory to implement cipher suite 3643 which provides certificate-based authentication of the server and is 3644 approved by NIST. The mandatory to implement cipher suites only 3645 include cipher suites that use strong cryptographic algorithms. They 3646 do not include cipher suites providing mutually anonymous 3647 authentication or static Diffie-Hellman cipher suites as defined in 3648 Section 3.2. 3650 A.6. Requirement 4.2.1.2 Tunnel Replay Protection 3652 TEAP v1 meets this requirement by using TLS to provide sufficient 3653 replay protection. 3655 A.7. Requirement 4.2.1.3 TLS Extensions 3657 TEAP v1 meets this requirement by allowing TLS extensions, such as 3658 TLS Certificate Status Request extension [RFC6066] and SessionTicket 3659 extension [RFC5077] to be used during TLS tunnel establishment. 3661 A.8. Requirement 4.2.1.4 Peer Identity Privacy 3663 TEAP v1 meets this requirement by establishment of the TLS tunnel and 3664 protection of inner method specific identities. In addition, the 3665 peer certificate can be sent confidentially (i.e. encrypted). 3667 A.9. Requirement 4.2.1.5 Session Resumption 3669 TEAP v1 meets this requirement by mandating support of TLS session 3670 resumption as defined in Section 3.2.1 and TLS Session Resume Using a 3671 PAC as defined in Section 3.2.2 . 3673 A.10. Requirement 4.2.2 Fragmentation 3675 TEAP v1 meets this requirement by leveraging fragmentation support 3676 provided by TLS as defined in Section 3.7. 3678 A.11. Requirement 4.2.3 Protection of Data External to Tunnel 3680 TEAP v1 meets this requirement by including TEAP version number 3681 received in the computation of crypto-binding TLV as defined in 3682 Section 4.2.13. 3684 A.12. Requirement 4.3.1 Extensible Attribute Types 3686 TEAP v1 meets this requirement by using an extensible TLV data layer 3687 inside the tunnel as defined in Section 4.2. 3689 A.13. Requirement 4.3.2 Request/Challenge Response Operation 3691 TEAP v1 meets this requirement by allowing multiple TLVs to be sent 3692 in a single EAP request or response packet, while maintaining the 3693 half-duplex operation typical of EAP. 3695 A.14. Requirement 4.3.3 Indicating Criticality of Attributes 3697 TEAP v1 meets this requirement by having a mandatory bit in TLV to 3698 indicate whether it is mandatory to support or not as defined in 3699 Section 4.2. 3701 A.15. Requirement 4.3.4 Vendor Specific Support 3703 TEAP v1 meets this requirement by having a Vendor-Specific TLV to 3704 allow vendors to define their own attributes as defined in 3705 Section 4.2.8. 3707 A.16. Requirement 4.3.5 Result Indication 3709 TEAP v1 meets this requirement by having a Result TLV to exchange the 3710 final result of the EAP authentication so both the peer and server 3711 have a synchronized state as defined in Section 4.2.4. 3713 A.17. Requirement 4.3.6 Internationalization of Display Strings 3715 TEAP v1 meets this requirement by supporting UTF-8 format in Basic- 3716 Password-Auth-Req TLV as defined in Section 4.2.14 and Basic- 3717 Password-Auth-Resp TLV as defined in Section 4.2.15. 3719 A.18. Requirement 4.4 EAP Channel Binding Requirements 3721 TEAP v1 meets this requirement by having a Channel-Binding TLV to 3722 exchange the EAP channel binding data as defined in Section 4.2.7. 3724 A.19. Requirement 4.5.1.1 Confidentiality and Integrity 3726 TEAP v1 meets this requirement by running the password authentication 3727 inside a protected TLS tunnel. 3729 A.20. Requirement 4.5.1.2 Authentication of Server 3731 TEAP v1 meets this requirement by mandating authentication of the 3732 server before establishment of the protected TLS and then running 3733 inner password authentication as defined in Section 3.2. 3735 A.21. Requirement 4.5.1.3 Server Certificate Revocation Checking 3737 TEAP v1 meets this requirement by supporting TLS Certificate Status 3738 Request extension [RFC6066] during tunnel establishment. 3740 A.22. Requirement 4.5.2 Internationalization 3742 TEAP v1 meets this requirement by supporting UTF-8 format in Basic- 3743 Password-Auth-Req TLV as defined in Section 4.2.14 and Basic- 3744 Password-Auth-Resp TLV as defined in Section 4.2.15. 3746 A.23. Requirement 4.5.3 Meta-data 3748 TEAP v1 meets this requirement by supporting Identity-Type TLV as 3749 defined in Section 4.2.3 to indicate whether the authentication is 3750 for a user or a machine. 3752 A.24. Requirement 4.5.4 Password Change 3754 TEAP v1 meets this requirement by supporting multiple Basic-Password- 3755 Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a 3756 single EAP authentication, which allows "housekeeping"" functions 3757 such as password change. 3759 A.25. Requirement 4.6.1 Method Negotiation 3761 TEAP v1 meets this requirement by supporting inner EAP method 3762 negotiation within the protected TLS tunnel. 3764 A.26. Requirement 4.6.2 Chained Methods 3766 TEAP v1 meets this requirement by supporting inner EAP method 3767 chaining within protected TLS tunnel as defined in Section 3.3.1. 3769 A.27. Requirement 4.6.3 Cryptographic Binding with the TLS Tunnel 3771 TEAP v1 meets this requirement by supporting cryptographic binding of 3772 the inner EAP method keys with the keys derived from the TLS tunnel 3773 as defined in Section 4.2.13. 3775 A.28. Requirement 4.6.4 Peer Initiated 3777 TEAP v1 meets this requirement by supporting Request-Action TLV as 3778 defined in Section 4.2.9 to allow peer to initiate another inner EAP 3779 method. 3781 A.29. Requirement 4.6.5 Method Meta-data 3783 TEAP v1 meets this requirement by supporting Identity-Type TLV as 3784 defined in Section 4.2.3 to indicate whether the authentication is 3785 for a user or a machine. 3787 Appendix B. Major Differences from EAP-FAST 3789 This document is a new standard tunnel EAP method based on revision 3790 of the EAP-FAST version 1 [RFC4851] which contains improved 3791 flexibility, particularly for negotiation of cryptographic 3792 algorithms. The major changes are: 3794 1. The EAP method name have been changed from EAP-FAST to TEAP, 3795 hence it would require a new EAP method type to be assigned. 3797 2. This version of TEAP MUST support TLS 1.2 [RFC5246]. 3799 3. The key derivation now makes use of TLS keying material exporters 3800 [RFC5705] and the PRF and hash function negotiated in TLS. This 3801 is to simplify implementation and better support cryptographic 3802 algorithm agility. 3804 4. TEAP is in full conformance with TLS Ticket extension [RFC5077] 3805 as described in Section 3.2.2. 3807 5. Support of passing optional outer TLVs in the first two message 3808 exchanges, in addition to the Authority-ID TLV data in EAP-FAST. 3810 6. Basic password authentication on the TLV level has been added in 3811 addition to the existing inner EAP method. 3813 7. Additional TLV types have been defined to support EAP channel 3814 binding and meta-data. They are Identity-Type TLV and Channel- 3815 Binding TLVs, defined in Section 4.2. 3817 Appendix C. Examples 3818 C.1. Successful Authentication 3820 The following exchanges show a successful TEAP authentication with 3821 basic password authentication and optional PAC refreshment, the 3822 conversation will appear as follows: 3824 Authenticating Peer Authenticator 3825 ------------------- ------------- 3826 <- EAP-Request/ 3827 Identity 3828 EAP-Response/ 3829 Identity (MyID1) -> 3831 <- EAP-Request/ 3832 EAP-Type=TEAP, V=1 3833 (TEAP Start, S bit set, Authority-ID) 3835 EAP-Response/ 3836 EAP-Type=TEAP, V=1 3837 (TLS client_hello with 3838 PAC-Opaque in SessionTicket extension)-> 3840 <- EAP-Request/ 3841 EAP-Type=TEAP, V=1 3842 (TLS server_hello, 3843 (TLS change_cipher_spec, 3844 TLS finished) 3846 EAP-Response/ 3847 EAP-Type=TEAP, V=1 -> 3848 (TLS change_cipher_spec, 3849 TLS finished) 3851 TLS channel established 3852 (messages sent within the TLS channel) 3854 <- Basic-Password-Auth-Req TLV, Challenge 3856 Basic-Password-Auth-Resp TLV, Response with both 3857 user name and password) -> 3859 optional additional exchanges (new pin mode, 3860 password change etc.) ... 3862 <- Crypto-Binding TLV (Request), 3863 Result TLV (Success), 3864 (Optional PAC TLV) 3866 Crypto-Binding TLV(Response), 3867 Result TLV (Success), 3868 (PAC TLV Acknowledgment) -> 3870 TLS channel torn down 3871 (messages sent in clear text) 3873 <- EAP-Success 3875 C.2. Failed Authentication 3877 The following exchanges show a failed TEAP authentication due to 3878 wrong user credentials, the conversation will appear as follows: 3880 Authenticating Peer Authenticator 3881 ------------------- ------------- 3882 <- EAP-Request/ 3883 Identity 3885 EAP-Response/ 3886 Identity (MyID1) -> 3888 <- EAP-Request/ 3889 EAP-Type=TEAP, V=1 3890 (TEAP Start, S bit set, Authority-ID) 3892 EAP-Response/ 3893 EAP-Type=TEAP, V=1 3894 (TLS client_hello with 3895 PAC-Opaque in SessionTicket extension)-> 3897 <- EAP-Request/ 3898 EAP-Type=TEAP, V=1 3899 (TLS server_hello, 3900 (TLS change_cipher_spec, 3901 TLS finished) 3903 EAP-Response/ 3904 EAP-Type=TEAP, V=1 -> 3905 (TLS change_cipher_spec, 3906 TLS finished) 3908 TLS channel established 3909 (messages sent within the TLS channel) 3911 <- Basic-Password-Auth-Req TLV, Challenge 3913 Basic-Password-Auth-Resp TLV, Response with both 3914 user name and password) -> 3916 <- Result TLV (Failure) 3918 Result TLV (Failure) -> 3920 TLS channel torn down 3921 (messages sent in clear text) 3923 <- EAP-Failure 3925 C.3. Full TLS Handshake using Certificate-based Cipher Suite 3927 In the case where an abbreviated TLS handshake is tried and failed 3928 and falls back to certificate based full TLS handshake occurs within 3929 TEAP Phase 1, the conversation will appear as follows: 3931 Authenticating Peer Authenticator 3932 ------------------- ------------- 3933 <- EAP-Request/Identity 3934 EAP-Response/ 3935 Identity (MyID1) -> 3937 // Identity sent in the clear. May be a hint to help route 3938 the authentication request to EAP server, instead of the 3939 full user identity. 3941 <- EAP-Request/ 3942 EAP-Type=TEAP, V=1 3943 (TEAP Start, S bit set, Authority-ID) 3944 EAP-Response/ 3945 EAP-Type=TEAP, V=1 3946 (TLS client_hello 3947 [PAC-Opaque extension])-> 3949 // Peer sends PAC-Opaque of Tunnel PAC along with a list of 3950 ciphersuites supported. If the server rejects the PAC- 3951 Opaque, if falls through to the full TLS handshake 3953 <- EAP-Request/ 3954 EAP-Type=TEAP, V=1 3955 (TLS server_hello, 3956 TLS certificate, 3957 [TLS server_key_exchange,] 3958 [TLS certificate_request,] 3959 TLS server_hello_done) 3960 EAP-Response/ 3961 EAP-Type=TEAP, V=1 3962 ([TLS certificate,] 3963 TLS client_key_exchange, 3964 [TLS certificate_verify,] 3965 TLS change_cipher_spec, 3966 TLS finished) -> 3967 <- EAP-Request/ 3968 EAP-Type=TEAP, V=1 3969 (TLS change_cipher_spec, 3970 TLS finished, 3971 EAP-Payload-TLV[EAP-Request/ 3972 Identity]) 3974 // TLS channel established 3975 (messages sent within the TLS channel) 3977 // First EAP Payload TLV is piggybacked to the TLS Finished as 3978 Application Data and protected by the TLS tunnel 3980 EAP-Payload-TLV 3981 [EAP-Response/Identity (MyID2)]-> 3983 // identity protected by TLS. 3985 <- EAP-Payload-TLV 3986 [EAP-Request/EAP-Type=X] 3988 EAP-Payload-TLV 3989 [EAP-Response/EAP-Type=X] -> 3991 // Method X exchanges followed by Protected Termination 3993 <- Intermediate-Result-TLV (Success), 3994 Crypto-Binding TLV (Request), 3995 Result TLV (Success) 3997 Intermediate-Result-TLV (Success), 3998 Crypto-Binding TLV (Response), 3999 Result-TLV (Success) -> 4001 // TLS channel torn down 4002 (messages sent in clear text) 4004 <- EAP-Success 4006 C.4. Client authentication during Phase 1 with identity privacy 4008 In the case where a certificate based TLS handshake occurs within 4009 TEAP Phase 1, and client certificate authentication and identity 4010 privacy is desired, therefore TLS renegotiation is being used to 4011 transmit the peer credentials in the protected TLS tunnel, the 4012 conversation will appear as follows: 4014 Authenticating Peer Authenticator 4015 ------------------- ------------- 4016 <- EAP-Request/Identity 4017 EAP-Response/ 4018 Identity (MyID1) -> 4020 // Identity sent in the clear. May be a hint to help route 4021 the authentication request to EAP server, instead of the 4022 full user identity. 4024 <- EAP-Request/ 4025 EAP-Type=TEAP, V=1 4026 (TEAP Start, S bit set, Authority-ID) 4027 EAP-Response/ 4028 EAP-Type=TEAP, V=1 4029 (TLS client_hello)-> 4030 <- EAP-Request/ 4031 EAP-Type=TEAP, V=1 4032 (TLS server_hello, 4033 TLS certificate, 4034 [TLS server_key_exchange,] 4035 [TLS certificate_request,] 4036 TLS server_hello_done) 4037 EAP-Response/ 4038 EAP-Type=TEAP, V=1 4039 (TLS client_key_exchange, 4040 TLS change_cipher_spec, 4041 TLS finished) -> 4042 <- EAP-Request/ 4043 EAP-Type=TEAP, V=1 4044 (TLS change_cipher_spec, 4045 TLS finished, 4046 EAP-Payload-TLV[EAP-Request/ 4047 Identity]) 4049 // TLS channel established 4050 (EAP Payload messages sent within the TLS channel) 4052 // peer sends TLS client_hello to request TLS renegotiation 4054 TLS client_hello -> 4056 <- TLS server_hello, 4057 TLS certificate, 4058 [TLS server_key_exchange,] 4059 [TLS certificate_request,] 4060 TLS server_hello_done 4061 [TLS certificate,] 4062 TLS client_key_exchange, 4063 [TLS certificate_verify,] 4064 TLS change_cipher_spec, 4065 TLS finished -> 4067 <- TLS change_cipher_spec, 4068 TLS finished, 4069 Crypto-Binding TLV (Request), 4070 Result TLV (Success) 4072 Crypto-Binding TLV (Response), 4073 Result-TLV (Success)) -> 4075 //TLS channel torn down 4076 (messages sent in clear text) 4078 <- EAP-Success 4080 C.5. Fragmentation and Reassembly 4082 In the case where TEAP fragmentation is required, the conversation 4083 will appear as follows: 4085 Authenticating Peer Authenticator 4086 ------------------- ------------- 4087 <- EAP-Request/ 4088 Identity 4089 EAP-Response/ 4090 Identity (MyID) -> 4091 <- EAP-Request/ 4092 EAP-Type=TEAP, V=1 4093 (TEAP Start, S bit set, Authority-ID) 4095 EAP-Response/ 4096 EAP-Type=TEAP, V=1 4097 (TLS client_hello)-> 4098 <- EAP-Request/ 4099 EAP-Type=TEAP, V=1 4100 (TLS server_hello, 4101 TLS certificate, 4102 [TLS server_key_exchange,] 4103 [TLS certificate_request,] 4104 TLS server_hello_done) 4105 (Fragment 1: L, M bits set) 4107 EAP-Response/ 4108 EAP-Type=TEAP, V=1 -> 4110 <- EAP-Request/ 4111 EAP-Type=TEAP, V=1 4112 (Fragment 2: M bit set) 4113 EAP-Response/ 4114 EAP-Type=TEAP, V=1 -> 4115 <- EAP-Request/ 4116 EAP-Type=TEAP, V=1 4117 (Fragment 3) 4118 EAP-Response/ 4119 EAP-Type=TEAP, V=1 4120 ([TLS certificate,] 4121 TLS client_key_exchange, 4122 [TLS certificate_verify,] 4123 TLS change_cipher_spec, 4124 TLS finished) 4125 (Fragment 1: L, M bits set)-> 4127 <- EAP-Request/ 4128 EAP-Type=TEAP, V=1 4129 EAP-Response/ 4130 EAP-Type=TEAP, V=1 4131 (Fragment 2)-> 4132 <- EAP-Request/ 4133 EAP-Type=TEAP, V=1 4134 (TLS change_cipher_spec, 4135 TLS finished, 4136 [EAP-Payload-TLV[ 4137 EAP-Request/Identity]]) 4139 // TLS channel established 4140 (messages sent within the TLS channel) 4142 // First EAP Payload TLV is piggybacked to the TLS Finished as 4143 Application Data and protected by the TLS tunnel 4145 EAP-Payload-TLV 4146 [EAP-Response/Identity (MyID2)]-> 4148 // identity protected by TLS. 4150 <- EAP-Payload-TLV 4151 [EAP-Request/EAP-Type=X] 4153 EAP-Payload-TLV 4154 [EAP-Response/EAP-Type=X] -> 4156 // Method X exchanges followed by Protected Termination 4158 <- Intermediate-Result-TLV (Success), 4159 Crypto-Binding TLV (Request), 4160 Result TLV (Success) 4162 Intermediate-Result-TLV (Success), 4163 Crypto-Binding TLV (Response), 4164 Result-TLV (Success) -> 4166 // TLS channel torn down 4167 (messages sent in clear text) 4169 <- EAP-Success 4171 C.6. Sequence of EAP Methods 4173 When TEAP is negotiated, with a sequence of EAP method X followed by 4174 method Y, the conversation will occur as follows: 4176 Authenticating Peer Authenticator 4177 ------------------- ------------- 4178 <- EAP-Request/ 4179 Identity 4180 EAP-Response/ 4181 Identity (MyID1) -> 4182 <- EAP-Request/ 4183 EAP-Type=TEAP, V=1 4184 (TEAP Start, S bit set, Authority-ID) 4186 EAP-Response/ 4187 EAP-Type=TEAP, V=1 4188 (TLS client_hello)-> 4189 <- EAP-Request/ 4190 EAP-Type=TEAP, V=1 4191 (TLS server_hello, 4192 TLS certificate, 4193 [TLS server_key_exchange,] 4194 [TLS certificate_request,] 4195 TLS server_hello_done) 4196 EAP-Response/ 4197 EAP-Type=TEAP, V=1 4198 ([TLS certificate,] 4199 TLS client_key_exchange, 4200 [TLS certificate_verify,] 4201 TLS change_cipher_spec, 4202 TLS finished) -> 4203 <- EAP-Request/ 4204 EAP-Type=TEAP, V=1 4205 (TLS change_cipher_spec, 4206 TLS finished, 4207 Identity-Type TLV, 4208 EAP-Payload-TLV[ 4209 EAP-Request/Identity]) 4211 // TLS channel established 4212 (messages sent within the TLS channel) 4214 // First EAP Payload TLV is piggybacked to the TLS Finished as 4215 Application Data and protected by the TLS tunnel 4217 Identity_Type TLV 4218 EAP-Payload-TLV 4219 [EAP-Response/Identity] -> 4221 <- EAP-Payload-TLV 4222 [EAP-Request/EAP-Type=X] 4224 EAP-Payload-TLV 4225 [EAP-Response/EAP-Type=X] -> 4227 // Optional additional X Method exchanges... 4229 <- EAP-Payload-TLV 4230 [EAP-Request/EAP-Type=X] 4232 EAP-Payload-TLV 4233 [EAP-Response/EAP-Type=X]-> 4235 <- Intermediate Result TLV (Success), 4236 Crypto-Binding TLV (Request), 4237 Identity-Type TLV, 4238 EAP Payload TLV [EAP-Type=Y], 4240 // Next EAP conversation started after successful completion 4241 of previous method X. The Intermediate-Result and Crypto- 4242 Binding TLVs are sent in next packet to minimize round- 4243 trips. In this example, identity request is not sent 4244 before negotiating EAP-Type=Y. 4246 // Compound MAC calculated using Keys generated from 4247 EAP methods X and the TLS tunnel. 4249 Intermediate Result TLV (Success), 4250 Crypto-Binding TLV (Response), 4251 EAP-Payload-TLV [EAP-Type=Y] -> 4253 // Optional additional Y Method exchanges... 4255 <- EAP Payload TLV [ 4256 EAP-Type=Y] 4258 EAP Payload TLV 4260 [EAP-Type=Y] -> 4262 <- Intermediate-Result-TLV (Success), 4263 Crypto-Binding TLV (Request), 4264 Result TLV (Success) 4266 Intermediate-Result-TLV (Success), 4267 Crypto-Binding TLV (Response), 4268 Result-TLV (Success) -> 4270 // Compound MAC calculated using Keys generated from EAP 4271 methods X and Y and the TLS tunnel. Compound Keys 4272 generated using Keys generated from EAP methods X and Y; 4273 and the TLS tunnel. 4275 // TLS channel torn down (messages sent in clear text) 4277 <- EAP-Success 4279 C.7. Failed Crypto-binding 4281 The following exchanges show a failed crypto-binding validation. The 4282 conversation will appear as follows: 4284 Authenticating Peer Authenticator 4285 ------------------- ------------- 4286 <- EAP-Request/ 4287 Identity 4288 EAP-Response/ 4289 Identity (MyID1) -> 4290 <- EAP-Request/ 4291 EAP-Type=TEAP, V=1 4292 (TEAP Start, S bit set, Authority-ID) 4294 EAP-Response/ 4295 EAP-Type=TEAP, V=1 4296 (TLS client_hello without 4297 PAC-Opaque extension)-> 4298 <- EAP-Request/ 4299 EAP-Type=TEAP, V=1 4300 (TLS Server Key Exchange 4301 TLS Server Hello Done) 4302 EAP-Response/ 4303 EAP-Type=TEAP, V=1 -> 4304 (TLS Client Key Exchange 4305 TLS change_cipher_spec, 4306 TLS finished) 4307 <- EAP-Request/ 4308 EAP-Type=TEAP, V=1 4309 (TLS change_cipher_spec 4310 TLS finished) 4311 EAP-Payload-TLV[ 4312 EAP-Request/Identity]) 4314 // TLS channel established 4315 (messages sent within the TLS channel) 4317 // First EAP Payload TLV is piggybacked to the TLS Finished as 4318 Application Data and protected by the TLS tunnel 4320 EAP-Payload TLV/ 4321 EAP Identity Response -> 4323 <- EAP Payload TLV, EAP-Request, 4324 (EAP-MSCHAPV2, Challenge) 4326 EAP Payload TLV, EAP-Response, 4327 (EAP-MSCHAPV2, Response) -> 4329 <- EAP Payload TLV, EAP-Request, 4330 (EAP-MSCHAPV2, Success Request) 4332 EAP Payload TLV, EAP-Response, 4333 (EAP-MSCHAPV2, Success Response) -> 4335 <- Intermediate-Result-TLV (Success), 4336 Crypto-Binding TLV (Request), 4337 Result TLV (Success) 4339 Intermediate-Result-TLV (Success), 4340 Result TLV (Failure) 4341 Error TLV with 4342 (Error Code = 2001) -> 4344 // TLS channel torn down 4345 (messages sent in clear text) 4347 <- EAP-Failure 4349 C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange 4351 When TEAP is negotiated, with a sequence of EAP method followed by 4352 Vendor-Specific TLV exchange, the conversation will occur as follows: 4354 Authenticating Peer Authenticator 4355 ------------------- ------------- 4356 <- EAP-Request/ 4357 Identity 4358 EAP-Response/ 4359 Identity (MyID1) -> 4360 <- EAP-Request/ 4361 EAP-Type=TEAP, V=1 4362 (TEAP Start, S bit set, Authority-ID) 4364 EAP-Response/ 4365 EAP-Type=TEAP, V=1 4366 (TLS client_hello)-> 4367 <- EAP-Request/ 4368 EAP-Type=TEAP, V=1 4369 (TLS server_hello, 4370 TLS certificate, 4371 [TLS server_key_exchange,] 4372 [TLS certificate_request,] 4373 TLS server_hello_done) 4375 EAP-Response/ 4376 EAP-Type=TEAP, V=1 4377 ([TLS certificate,] 4378 TLS client_key_exchange, 4379 [TLS certificate_verify,] 4380 TLS change_cipher_spec, 4381 TLS finished) -> 4382 <- EAP-Request/ 4383 EAP-Type=TEAP, V=1 4384 (TLS change_cipher_spec, 4385 TLS finished, 4386 EAP-Payload-TLV[ 4387 EAP-Request/Identity]) 4389 // TLS channel established 4390 (messages sent within the TLS channel) 4392 // First EAP Payload TLV is piggybacked to the TLS Finished as 4393 Application Data and protected by the TLS tunnel 4395 EAP-Payload-TLV 4396 [EAP-Response/Identity] -> 4398 <- EAP-Payload-TLV 4399 [EAP-Request/EAP-Type=X] 4401 EAP-Payload-TLV 4402 [EAP-Response/EAP-Type=X] -> 4403 <- EAP-Payload-TLV 4404 [EAP-Request/EAP-Type=X] 4406 EAP-Payload-TLV 4407 [EAP-Response/EAP-Type=X]-> 4409 <- Intermediate Result TLV (Success), 4410 Crypto-Binding TLV (Request), 4411 Vendor-Specific TLV, 4413 // Vendor Specific TLV exchange started after successful 4414 completion of previous method X. The Intermediate-Result 4415 and Crypto-Binding TLVs are sent with Vendor Specific TLV 4416 in next packet to minimize round-trips. 4418 // Compound MAC calculated using Keys generated from 4419 EAP methods X and the TLS tunnel. 4421 Intermediate Result TLV (Success), 4422 Crypto-Binding TLV (Response), 4423 Vendor-Specific TLV -> 4425 // Optional additional Vendor-Specific TLV exchanges... 4427 <- Vendor-Specific TLV 4429 Vendor Specific TLV -> 4430 <- Result TLV (Success) 4432 Result-TLV (Success) -> 4434 // TLS channel torn down (messages sent in clear text) 4436 <- EAP-Success 4438 C.9. Peer Requests Inner Method After Server Sends Result TLV 4440 In the case where the peer is authenticated during Phase 1 and server 4441 sends back result TLV, but the peers wants to request another inner 4442 method, the conversation will appear as follows: 4444 Authenticating Peer Authenticator 4445 ------------------- ------------- 4446 <- EAP-Request/Identity 4447 EAP-Response/ 4448 Identity (MyID1) -> 4450 // Identity sent in the clear. May be a hint to help route 4451 the authentication request to EAP server, instead of the 4452 full user identity. 4454 <- EAP-Request/ 4455 EAP-Type=TEAP, V=1 4456 (TEAP Start, S bit set, Authority-ID) 4457 EAP-Response/ 4458 EAP-Type=TEAP, V=1 4459 (TLS client_hello)-> 4460 <- EAP-Request/ 4461 EAP-Type=TEAP, V=1 4462 (TLS server_hello, 4463 TLS certificate, 4464 [TLS server_key_exchange,] 4465 [TLS certificate_request,] 4466 TLS server_hello_done) 4467 EAP-Response/ 4468 EAP-Type=TEAP, V=1 4469 [TLS certificate,] 4470 TLS client_key_exchange, 4471 [TLS certificate_verify,] 4472 TLS change_cipher_spec, 4473 TLS finished -> 4474 <- EAP-Request/ 4475 EAP-Type=TEAP, V=1 4476 (TLS change_cipher_spec, 4477 TLS finished, 4478 Crypto-Binding TLV (Request), 4479 Result TLV (Success)) 4481 // TLS channel established 4482 (TLV Payload messages sent within the TLS channel) 4484 Crypto-Binding TLV(Response), 4485 Request-Action TLV 4486 (Status=Failure, Action=Negotiate-EAP)-> 4488 <- EAP-Payload-TLV 4489 [EAP-Request/Identity] 4491 EAP-Payload-TLV 4492 [EAP-Response/Identity] -> 4494 <- EAP-Payload-TLV 4495 [EAP-Request/EAP-Type=X] 4497 EAP-Payload-TLV 4498 [EAP-Response/EAP-Type=X] -> 4499 <- EAP-Payload-TLV 4500 [EAP-Request/EAP-Type=X] 4502 EAP-Payload-TLV 4503 [EAP-Response/EAP-Type=X]-> 4505 <- Intermediate Result TLV (Success), 4506 Crypto-Binding TLV (Request), 4507 Result TLV (Success) 4509 Intermediate Result TLV (Success), 4510 Crypto-Binding TLV (Response), 4511 Result-TLV (Success)) -> 4513 //TLS channel torn down 4514 (messages sent in clear text) 4516 <- EAP-Success 4518 C.10. Channel Binding 4520 The following exchanges show a successful TEAP authentication with 4521 basic password authentication and channel binding using Request- 4522 Action TLV, the conversation will appear as follows: 4524 Authenticating Peer Authenticator 4525 ------------------- ------------- 4526 <- EAP-Request/ 4527 Identity 4528 EAP-Response/ 4529 Identity (MyID1) -> 4531 <- EAP-Request/ 4532 EAP-Type=TEAP, V=1 4533 (TEAP Start, S bit set, Authority-ID) 4535 EAP-Response/ 4536 EAP-Type=TEAP, V=1 4537 (TLS client_hello with 4538 PAC-Opaque in SessionTicket extension)-> 4540 <- EAP-Request/ 4541 EAP-Type=TEAP, V=1 4542 (TLS server_hello, 4543 (TLS change_cipher_spec, 4544 TLS finished) 4546 EAP-Response/ 4547 EAP-Type=TEAP, V=1 -> 4548 (TLS change_cipher_spec, 4549 TLS finished) 4551 TLS channel established 4552 (messages sent within the TLS channel) 4554 <- Basic-Password-Auth-Req TLV, Challenge 4556 Basic-Password-Auth-Resp TLV, Response with both 4557 user name and password) -> 4559 optional additional exchanges (new pin mode, 4560 password change etc.) ... 4562 <- Crypto-Binding TLV (Request), 4563 Result TLV (Success), 4565 Crypto-Binding TLV(Response), 4566 Request-Action TLV 4567 (Status=Failure, Action=Process-TLV, 4568 TLV=Channel-Binding TLV)-> 4570 <- Channel-Binding TLV (Response), 4571 Result TLV (Success), 4573 Result-TLV (Success) -> 4575 TLS channel torn down 4576 (messages sent in clear text) 4578 <- EAP-Success 4580 Appendix D. Major Differences from Previous Revisions 4582 D.1. Changes from -06 4584 1 Removed Design Goals 4586 2 Added restriction on ciphersuites that do not provide 4587 confidentiality in section 3.2 4589 3 Added clarification of TLS unique used during certificate 4590 provisioning in section 3.8.2 4592 4 Specified DER encoding for PKCS#7 and PKCS#10 TLVs 4594 5 Removed details of PKCS#7 package to RFC5652 4595 6 Moved RFC 4851 to informative reference 4597 7 Additional editorial changes to address Security AD review 4598 comments. 4600 D.2. Changes from -05 4602 1 Section 3.3.3, clarified that Intermediate Result TLV and Crypto- 4603 Binding TLV MUST be exchanged after each EAP method, even with a 4604 single inner EAP method. 4606 2 Section 3.5, clarified that tls-unique is from Phase outer TLS 4607 tunnel before beginning of the Phase 2. 4609 3 Section 3.6.3, added text to handle processing inner method error. 4611 4 Section 3.8, added a section titled Peer Services, stressing 4612 mutual authentication before rest of peer services. 4614 5 Section 3.8,4, added a section describing channel binding flows. 4616 6 Section 7.6, changed SHOULD to MUST for matching server 4617 certificate realm portion. 4619 7 Update references from I-Ds to RFCs. 4621 D.3. Changes from -04 4623 1 Section 3.2, clarified that requesting new PAC in abbreviated 4624 handshake is not permitted. 4626 2 Section 3.6.2, clarified that TLS restart is not allowed for fatal 4627 Alerts. 4629 3 Section 3.6.3, added text to handle processing inner method error. 4631 4 Section 4.1, clarified Flags bit usage. 4633 5 Section 4.2.3, clarified Identity-Type TLV usage. 4635 6 Section 4.2.8, clarified mandatory bit in Vendor-Specific TLV. 4637 7 Section 4.2.13, added Compound MAC presence indicator in Crypto- 4638 Binding TLV. 4640 D.4. Changes from -03 4642 1 Section 4.1, added optional Outer TLV Length field and flag in 4643 TEAP packet format. 4645 2 Section 4.3, added TLV processing rules and rules for outer TLVs. 4647 3 Section 5.2, changed IMCK generation from MSK based to either EMSK 4648 or MSK with corresponding rules. 4650 4 Section 4.2.13, introduced two Compound MAC fields for Crypto- 4651 Binding TLV. 4653 5 Section 3.4, clarified that all authenticated Peer-Ids, Server-Ids 4654 and their identity types need to be exported. 4656 6 Section 5.1, changed TLS Keying Material Exporter label to 4657 "EXPORTER: teap session key seed". 4659 7 Section 4.2.9, clarified Request-Action TLV processing. 4661 D.5. Changes from -02 4663 1 Section 3.3.3, clarified protected termination and use of crypto- 4664 binding TLV. 4666 2 Section 3.5, changed Session ID to use tls-unique and added 4667 reference to RFC5247. 4669 3 Section 3.9, added the use of tls-unique to the certificate 4670 enrollment request. 4672 4 Section 4.2.9, modified Request-Action TLV to include Status code 4673 and optional TLVs. 4675 5 Section 3.4, clarified that all authenticated Peer-Ids need to be 4676 exported. 4678 6 Section 5.1, changed TLS Keying Material Exporter label to "teap 4679 session key seed". 4681 7 Section 5.2, changed Intermediate Compound Key Derivation from MSK 4682 to EMSK generated by inner method. 4684 8 Section 6, added missing IANA considerations. 4686 9 Section 7.3, added more security considerations for separation of 4687 Phase 1 and Phase 2 servers. 4689 10 Appendix C, updated examples with Request-Action TLV, channel 4690 binding, and sending certificate after TLS renegotiation. 4692 D.6. Changes from -01 4694 1 In Version Negotiation section, clarified what the peer needs to 4695 do if the supported version is higher than what the server 4696 proposed. 4698 2 Section 3.2, clarified the requirement for using anonymous cipher 4699 suites. 4701 3 Clarified that Crypto-binding TLV is always exchanged and 4702 validated, even without inner methods. 4704 4 Section 3.4, clarified that all authenticated Peer-Ids need to be 4705 exported. 4707 5 Clarified that channel-binding TLV can be used to transmit data 4708 bidirectionally. 4710 6 Updated obsolete RFC references 4712 7 Renumbered TLVs to eliminate gaps 4714 8 Updated examples with basic password authentication TLVs. 4716 9 Added Certificate Provisioning Within the Tunnel. 4718 10 Added Server Unauthenticated Provisioning Mode. 4720 D.7. Changes from -00 4722 1 Changed protocol name to TEAP: Tunnel EAP Method 4724 2 Changed version of protocol to version 1 4726 3 Revised introduction 4728 4 Moved differences section to appendix 4730 5 Revised design goals section 4732 6 Revised PAC definition 4734 7 Revised protocol description to be in line with RFC 5077 PAC 4735 distribution 4737 8 Revised EAP Sequences Section 4739 9 Added section on PAC provisioning within tunnel 4741 10 Added outer TLVs to the message format 4743 11 Renumbered TLVs 4745 12 Included PAC TLVs 4747 13 Added Authority ID TLV 4749 14 Added PKCS#7 and server trust root TLV definitions 4751 15 Added PKCS#10 TLV 4753 16 PKCS#10 TLV 4755 17 Added EAP-Type and outer TLVs to crypto binding compound MAC 4757 Authors' Addresses 4759 Hao Zhou 4760 Cisco Systems 4761 4125 Highlander Parkway 4762 Richfield, OH 44286 4763 US 4765 EMail: hzhou@cisco.com 4767 Nancy Cam-Winget 4768 Cisco Systems 4769 3625 Cisco Way 4770 San Jose, CA 95134 4771 US 4773 EMail: ncamwing@cisco.com 4775 Joseph Salowey 4776 Cisco Systems 4777 2901 3rd Ave 4778 Seattle, WA 98121 4779 US 4781 EMail: jsalowey@cisco.com 4782 Stephen Hanna 4783 Juniper Networks 4784 79 Parsons Street 4785 Brighton, MA 02135 4786 US 4788 EMail: shanna@juniper.net