idnits 2.17.00 (12 Aug 2021) /tmp/idnits35671/draft-zorn-emu-team-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2011) is 4085 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) -- No information found for draft-zorn-emu-eap-pwc - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.zorn-emu-eap-pwc' ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: draft-ietf-emu-eaptunnel-req has been published as RFC 6678 -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track Q. Wu 5 Expires: September 9, 2011 Huawei 6 D. Harkins 7 Aruba Networks 8 March 8, 2011 10 The Tunneled Extensible Authentication Method (TEAM) 11 draft-zorn-emu-team-02 13 Abstract 15 The Extensible Authentication Protocol (EAP) provides support for 16 multiple authentication methods. This document defines the Tunneled 17 Extensible Authentication Method (TEAM), which provides an encrypted 18 and authenticated tunnel based on transport layer security (TLS) that 19 encapsulates EAP authentication mechanisms. TEAM uses TLS to protect 20 against rogue authenticators, protect against various attacks on the 21 confidentiality and integrity of the inner EAP method exchange and 22 provide EAP peer identity privacy. TEAM also provides support for 23 chaining multiple EAP mechanisms, cryptographic binding between 24 authentications performed by inner EAP mechanisms and the tunnel, 25 exchange of arbitrary parameters (TLVs), and fragmentation and 26 reassembly. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. This document may not be modified, 32 and derivative works of it may not be created, except to format it 33 for publication as an RFC or to translate it into languages other 34 than English. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 9, 2011. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Operational Model . . . . . . . . . . . . . . . . . . . . 8 69 4.2. Sequences . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3. TEAM Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.3.1. Initial identity exchange . . . . . . . . . . . . . . 10 72 4.3.2. TLS Session Establishment . . . . . . . . . . . . . . 11 73 4.3.3. Session Resumption . . . . . . . . . . . . . . . . . . 13 74 4.3.4. Version Negotiation . . . . . . . . . . . . . . . . . 14 75 4.4. TEAM Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.4.1. Protected Conversation . . . . . . . . . . . . . . . . 15 77 4.4.2. Protected Termination . . . . . . . . . . . . . . . . 18 78 4.4.3. Provisioning of Credentials . . . . . . . . . . . . . 19 79 4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 21 80 4.6. Fragmentation and Reassembly . . . . . . . . . . . . . . . 22 81 4.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 24 82 4.7.1. Compound Session Key Derivation . . . . . . . . . . . 25 83 4.8. Ciphersuite Negotiation . . . . . . . . . . . . . . . . . 26 84 5. TEAM Protocol Description . . . . . . . . . . . . . . . . . . 26 85 5.1. TEAM Protocol Layers . . . . . . . . . . . . . . . . . . . 26 86 5.2. TEAM Packet Format . . . . . . . . . . . . . . . . . . . . 27 87 6. Type-Length-Value Tuples . . . . . . . . . . . . . . . . . . . 29 88 6.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 30 89 6.2. Result TLV . . . . . . . . . . . . . . . . . . . . . . . . 31 90 6.3. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . . . 32 91 6.4. Error-Code TLV . . . . . . . . . . . . . . . . . . . . . . 33 92 6.5. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . . . 34 93 6.6. Connection-Binding TLV . . . . . . . . . . . . . . . . . . 36 94 6.7. Vendor-Specific TLV . . . . . . . . . . . . . . . . . . . 38 95 6.8. URI TLV . . . . . . . . . . . . . . . . . . . . . . . . . 39 96 6.9. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . . . 40 97 6.10. Intermediate-Result TLV . . . . . . . . . . . . . . . . . 41 98 6.11. Calling-Station-Id TLV . . . . . . . . . . . . . . . . . . 42 99 6.12. Called-Station-Id TLV . . . . . . . . . . . . . . . . . . 43 100 6.13. NAS-Port-Type TLV . . . . . . . . . . . . . . . . . . . . 45 101 6.14. Server-Identifier TLV . . . . . . . . . . . . . . . . . . 46 102 6.15. Identity-Type TLV . . . . . . . . . . . . . . . . . . . . 47 103 6.16. Server-Trusted-Root TLV . . . . . . . . . . . . . . . . . 48 104 6.17. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . . . . 49 105 6.18. Request-Action-TLV . . . . . . . . . . . . . . . . . . . . 50 106 6.19. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 51 107 6.19.1. Outer TLVs . . . . . . . . . . . . . . . . . . . . . . 52 108 6.19.2. Inner TLVs . . . . . . . . . . . . . . . . . . . . . . 53 109 6.19.3. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 54 110 6.19.4. Connection-Binding TLV . . . . . . . . . . . . . . . . 54 111 6.19.5. Server-Trusted-Root TLV . . . . . . . . . . . . . . . 54 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 113 7.1. Authentication and Integrity Protection . . . . . . . . . 55 114 7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . . 55 115 7.3. TLS Session Cache Handling . . . . . . . . . . . . . . . . 56 116 7.4. Certificate Revocation . . . . . . . . . . . . . . . . . . 57 117 7.5. Separation of EAP Server and Authenticator . . . . . . . . 58 118 7.6. Separation of TEAM Phase 1 and 2 Servers . . . . . . . . . 58 119 7.7. Identity Verification . . . . . . . . . . . . . . . . . . 60 120 7.8. Man-in-the-Middle Attack Protection . . . . . . . . . . . 61 121 7.9. Cleartext Forgeries . . . . . . . . . . . . . . . . . . . 62 122 7.10. TLS Ciphersuites . . . . . . . . . . . . . . . . . . . . . 63 123 7.11. Denial of Service Attacks . . . . . . . . . . . . . . . . 63 124 7.12. Server Unauthenticated Tunnel Provisioning Mode . . . . . 64 125 7.13. Security Claims . . . . . . . . . . . . . . . . . . . . . 65 126 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 127 8.1. EAP Type . . . . . . . . . . . . . . . . . . . . . . . . . 67 128 8.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 67 129 8.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 67 130 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 67 131 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 132 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 133 11.1. Normative References . . . . . . . . . . . . . . . . . . . 68 134 11.2. Informative References . . . . . . . . . . . . . . . . . . 69 135 Appendix A. Compliance with Requirements for a Tunnel Based 136 EAP Method . . . . . . . . . . . . . . . . . . . . . 71 137 A.1. General Requirements . . . . . . . . . . . . . . . . . . . 71 138 A.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 71 139 A.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 72 140 A.4. Channel Binding Requirements . . . . . . . . . . . . . . . 72 141 A.5. Username/Password Requirements . . . . . . . . . . . . . . 72 142 A.6. Requirements Around Carriage of EAP Methods . . . . . . . 73 144 1. Introduction 146 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 147 provides support for multiple authentication methods. EAP over PPP 148 [RFC3748] is typically deployed with leased lines or modem 149 connections. [IEEE.802-1X.2004] defines EAP over IEEE 802 local area 150 networks (EAPOL). 152 Since its initial development, a number of weaknesses in the EAP 153 framework have become apparent. These include lack of support for: 155 Identity protection 156 Protected method negotiation 157 Protected notification messages 158 Protected termination messages 159 Sequences of EAP methods 160 Fragmentation and reassembly 161 Exchange of arbitrary parameters in a secure channel 162 Optimized re-authentication 164 In addition, some EAP methods lack the following features: 166 Mutual authentication 167 Resistance to dictionary attacks 168 Adequate key generation 170 By wrapping the EAP protocol within TLS, TEAM addresses deficiencies 171 in EAP or EAP methods. Benefits of TEAM include: 173 Identity protection 174 By encrypting the identity exchange, and allowing client identity 175 to be provided after negotiation of the TLS channel, TEAM provides 176 for identity protection. 178 Dictionary attack resistance 179 By conducting the EAP conversation within a TLS channel, TEAM 180 protects EAP methods that might be subject to an offline 181 dictionary attack were they to be conducted in the clear. 183 Protected negotiation 184 Since within TEAM, the EAP conversation is authenticated, 185 integrity and replay protected on a per-packet basis, the EAP 186 method negotiation that occurs within TEAM is protected, as are 187 error messages sent within the TLS channel (TLS alerts or EAP 188 Notification packets). EAP negotiation outside of TEAM is not 189 protected. 191 Header protection 192 Within TEAM, TLS provides per-packet encryption, authentication, 193 integrity and replay protection for the EAP conversation. As a 194 result, the Type-Data field within TEAM (including the EAP header 195 of the EAP method within TEAM) is protected against modification. 196 However, the EAP header of TEAM itself is not protected against 197 modification, including the Code, Identifier and Type fields. 199 Protected termination 200 By sending success/failure indications within the TLS channel, 201 TEAM provides support for protected termination of the EAP 202 conversation. This prevents an attacker from carrying out denial 203 of service attacks by spoofing EAP Failure messages, or fooling 204 the EAP peer into accepting a rogue NAS, by spoofing EAP Success 205 messages. 207 Fragmentation and Reassembly 208 Since EAP does not include support for fragmentation and 209 reassembly, individual methods need to include this capability. 210 By including support for fragmentation and reassembly within TEAM, 211 methods leveraging TEAM do not need to support this on their own. 213 Fast reconnect 214 Where EAP is used for authentication in wireless networks, the 215 authentication latency is a concern. As a result, it is valuable 216 to be able to do a quick re-authentication on roaming between 217 access points. TEAM supports this capability by leveraging the 218 TLS session resumption facility, and any EAP method running under 219 TEAM can take advantage of it. 221 Standard key establishment 222 In order to provide keying material for a wide range of link layer 223 ciphersuites, EAP methods need to provide keying material. Key 224 derivation is complex. TEAM provides for key establishment by 225 relying on the widely implemented and well-reviewed TLS [RFC5246] 226 key derivation mechanism. TEAM provides keying material for any 227 EAP method running within it. 229 Sequencing of multiple EAP methods 230 In order to enhance security, TEAM implementations may choose to 231 provide multi-factor authentication that validates different 232 identities (for example user and machine identities) and/or uses 233 different credentials of the same or different identities of the 234 peer (e.g. user password and machine cert). TEAM provides a 235 standard way to chain different types of authentication mechanisms 236 supporting different types of credentials. 238 Protected exchange of arbitrary parameters 239 Type-Length-Value (TLV) tuples provide a way to exchange arbitrary 240 information between peer and EAP server within a secure channel. 241 This information can include signaling parameters for the EAP 242 protocol, provisioning parameters, media specific and environment 243 specific data, and authorization parameters. The advantage of 244 using TEAM TLVs is that every EAP method does not have to be 245 modified. 247 Credential provisioning 248 TEAM supports provisioning of certificate trust anchors by the 249 server using TLVs and can be extended to support provisioning of 250 other peer credentials. 252 Optimized for light weight devices 253 In order to support peers that may not support certificate 254 ciphersuites, and may not support provisioning of certificate 255 trust anchors, TEAM enables negotiation of other TLS ciphersuites. 257 Server unauthenticated tunnel provisioning mode 258 In some cases, the peer may only support password credentials and 259 may not be provisioned with a certificate trust anchor. 261 In server unauthenticated tunnel provisioning mode, a TEAM peer 262 can authenticate using a password, in order to be provisioned with 263 a pre-shared key and other credentials that can be used for 264 subsequent authentication. In server unauthenticated tunnel 265 provisioning mode the TEAM peer does not authenticate the server. 266 As a result, it is possible for an attacker to act as a man-in- 267 the-middle during the initial exchange in order to attack the 268 inner exchange. For this reason, when performing server 269 unauthenticated tunnel provisioning mode the inner method MUST be 270 resistant to dictionary attack. 272 2. Requirements Language 274 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 275 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 276 document are to be interpreted as described in [RFC2119]. 278 3. Terminology 280 This document frequently uses the following terms: 282 Access Point 283 A Network Access Server implementing 802.11. 285 Authenticator 286 The end of the link initiating EAP authentication. This term is 287 also used in [IEEE.802-1X.2004]. and has the same meaning in this 288 document. 290 Backend Authentication Server 291 A backend authentication server is an entity that provides an 292 authentication service to an Authenticator. When used, this 293 server typically executes EAP methods for the Authenticator. This 294 terminology is also used in [IEEE.802-1X.2004]. 296 EAP server 297 The entity that terminates the EAP authentication method with the 298 peer. In the case where no backend authentication server is used, 299 the EAP server is part of the Authenticator. In the case where 300 the authenticator operates in pass-through mode, the EAP server is 301 located on the backend authentication server. 303 Link layer ciphersuite 304 The ciphersuite negotiated for use at the link layer. 306 NAS 307 Short for "Network Access Server". 309 Peer 310 The end of the link that responds to the authenticator. In 311 [IEEE.802-1X.2004], this end is known as the Supplicant. 313 TLS Ciphersuite 314 The ciphersuite negotiated for protection of Phase 2 of the TEAM 315 conversation Section 4.4. 317 EAP Master key (MK) 318 A key derived between the TEAM client and server during the 319 authentication conversation, and that is kept local to TEAM and 320 not exported or made available to a third party. 322 Master Session Key (MSK) 323 Keying material that is derived between the EAP peer and server 324 and exported by the EAP method. The MSK is at least 64 octets in 325 length. In existing implementations, a AAA server acting as an 326 EAP server transports the MSK to the authenticator. 328 Extended Master Session Key (EMSK) 329 Additional keying material derived between the EAP client and 330 server that is exported by the EAP method. The EMSK is at least 331 64 octets in length. The EMSK is not shared with the 332 authenticator or any other third party. The EMSK is reserved for 333 future uses that are not defined yet. 335 Type Length Value (TLV) 336 The TEAM protocol utilizes objects in Type Length Value (TLV) 337 format. The TLV format is defined in Section 6.1 of this 338 document. 340 4. Protocol Overview 342 TEAM is comprised of a two-part conversation: 344 1. In Phase 1 a TLS session is negotiated, with the server 345 authenticating to the client and (optionally) the client to the 346 server. The negotiated key is then used to protect Phase 2 of 347 the conversation. 349 2. In Phase 2, within the TLS session, zero or more EAP methods are 350 carried out. Phase 2 completes with a success/failure indication 351 protected by the TLS session or a protected error (TLS alert). 353 In the following sections, we discuss the TEAM operational model, its 354 support for EAP method sequencing and provide an overview of each of 355 the parts of the TEAM conversation. 357 4.1. Operational Model 359 In EAP, the EAP server may be implemented either within a Network 360 Access Server (NAS) or on a backend authentication server. Where the 361 EAP server resides on a NAS, the NAS is required to implement the 362 desired EAP methods, and therefore needs to be upgraded to support 363 each new EAP method. 365 One of the goals of EAP is to enable development of new 366 authentication methods without requiring deployment of new code on 367 the Network Access Server (NAS). Where a backend authentication 368 server is deployed, the NAS acts as a "passthrough" and need not 369 understand specific EAP methods. 371 This allows new EAP methods to be deployed on the EAP peer and 372 backend authentication server, without the need to upgrade code 373 residing on the NAS. 375 Figure 1 illustrates the relationship between the EAP peer, NAS and 376 EAP server. As shown in the figure, the EAP conversation occurs 377 between the EAP peer and EAP server, "passing through" the NAS. In 378 order for the conversation to proceed in the case where the NAS and 379 EAP server reside on separate machines, the NAS and EAP server need 380 to establish trust beforehand. 382 +-+-+-+-+-+ +-+-+-+-+-+ 383 | | | | 384 | Link | | Link | 385 | Layer | | Layer | 386 | Cipher- | | Cipher- | 387 | Suite | | Suite | 388 | | | | 389 +-+-+-+-+-+ +-+-+-+-+-+ 390 ^ ^ 391 | | 392 | | 393 | | 394 V V 395 +-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+ 396 | | EAP | |<======>| | 397 | | Conversation | | | | 398 | EAP |<================================>| EAP | 399 | Peer | (over PPP, | NAS | | Server | 400 | | 802.11,etc.) | |<=======| | 401 | | | | Keys | | 402 | | | | | | 403 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 404 ^ ^ 405 | | 406 | EAP API | EAP API 407 | | 408 V V 409 +-+-+-+-+-+ +-+-+-+-+-+ 410 | | | | 411 | | | | 412 | EAP | | EAP | 413 | Method | | Method | 414 | | | | 415 +-+-+-+-+-+ +-+-+-+-+-+ 417 Figure 1: Relationship between EAP client, backend authentication 418 server and NAS 420 In TEAM, the conversation between the EAP peer and the EAP server is 421 encrypted, authenticated, integrity and replay protected within a TLS 422 channel. 424 As a result, where the NAS acts as a "passthrough" it does not have 425 knowledge of the TLS master secret derived between the peer and the 426 EAP server. In order to provide keying material for link-layer 427 ciphersuites, the NAS obtains the master session key, which is 428 derived from a one-way function of the TLS master secret as well as 429 keying material provided by EAP methods protected within a TLS 430 channel. This enables the NAS and EAP peer to subsequently derive 431 transient session keys suitable for encrypting, authenticating and 432 integrity protecting session data. However, the NAS cannot decrypt 433 the TEAM conversation or spoof session resumption, since this 434 requires knowledge of the TLS master secret. 436 4.2. Sequences 438 EAP [RFC3748] prohibits use of multiple authentication methods within 439 a single EAP conversation, except when tunneled methods such as TEAM 440 are used. This restriction was imposed in order to limit 441 vulnerabilities to man-in-the-middle attacks as well as to ensure 442 compatibility with existing EAP implementations. 444 Within TEAM these concerns are addressed since TEAM includes support 445 for cryptographic binding to address man-in-the-middle attacks, as 446 well as version negotiation so as to enable backward compatibility 447 with future versions of the protocol. 449 Within this document, the term "sequence" refers to a series of EAP 450 authentication methods run in sequence or TLV exchanges before or 451 after EAP methods. The methods need not be distinct - for example, 452 EAP-TLS could be run initially with machine credentials followed by 453 the same protocol authenticating with user credentials. 455 TEAM supports initiating additional EAP method(s) after a successful 456 or a failed EAP method. The result of failure of a EAP method does 457 not always imply a failure of the overall authentication. The 458 overall result of authentication depends on the policy at EAP server 459 and the peer. For example, successful authentication might require a 460 successful machine authentication followed by a successful user 461 authentication. Alternatively, if machine authentication fails, then 462 user authentication can be attempted. TEAM does not support 463 initiating multiple EAP methods simultaneously. 465 4.3. TEAM Phase 1 467 4.3.1. Initial identity exchange 469 The TEAM conversation typically begins with an optional identity 470 exchange. The authenticator will typically send an EAP-Request/ 471 Identity packet to the peer, and the peer will respond with an EAP- 472 Response/Identity packet to the authenticator. 474 The initial identity exchange is used primarily to route the EAP 475 conversation to the EAP server. Since the initial identity exchange 476 is in the clear, the peer MAY decide to place a routing realm instead 477 of its real name in the EAP-Response/Identity. The real identity of 478 the peer can be established later, during Phase 2. 480 If the EAP server is known in advance (such as when all users 481 authenticate against the same backend server infrastructure and 482 roaming is not supported), or if the identity is otherwise determined 483 (such as from the dialing phone number or client MAC address), then 484 the Identity exchange MAY be omitted. 486 Once the optional initial Identity Request/Response exchange is 487 completed, while nominally the EAP conversation occurs between the 488 authenticator and the peer, the authenticator MAY act as a 489 passthrough device, with the EAP packets received from the peer being 490 encapsulated for transmission to a backend authentication server. 491 However, TEAM does not require a backend authentication server; if 492 the authenticator implements TEAM, then it can authenticate local 493 users. 495 In the discussion that follows, we will use the term "EAP server" to 496 denote the ultimate endpoint conversing with the peer. 498 4.3.2. TLS Session Establishment 500 In this section, the protocol is described. While this section will 501 often describe negotiation of a certificate-based ciphersuite within 502 TLS, TEAM supports negotiation of other ciphersuites (for example, 503 ciphersuites that do not use certificates) or extensions. However, 504 the conversation may slightly differ if other TLS ciphersuites or 505 extensions are used. 507 Once having received the peer's identity, and determined that TEAM 508 authentication is to occur, the EAP server MUST respond with a TEAM/ 509 Start packet, which is an EAP-Request packet with EAP-Type=TEAM, the 510 Start (S) bit set, the TEAM version as specified in Section 4.3.4, 511 and optionally, the Server-Identifier TLV (Section 6.14). 513 Assuming that the peer supports TEAM, the TEAM conversation will then 514 begin, with the peer sending an EAP-Response packet with EAP- 515 Type=TEAM. The Type-Data field of the EAP-Response Packet will 516 encapsulate one or more TLS records containing the TLS handshake 517 messages. As defined in [RFC5246], the TLS handshake is used to 518 negotiate parameters and cryptographic keys and may take several 519 roundtrips between the TLS client and server. 521 The version offered by the TLS client and server MUST be TLS v1.0 or 522 later. TEAM implementations need not necessarily support all TLS 523 ciphersuites listed in [RFC5246]. Not all TLS ciphersuites are 524 supported by available TLS tool kits and licenses may be required in 525 some cases. 527 To ensure interoperability, TEAM peers and servers MUST support the 528 TLS v1.1 [RFC5246] mandatory-to-implement ciphersuite: 530 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 532 In addition, TEAM servers SHOULD support and be able to negotiate all 533 of the following TLS ciphersuites: 535 TLS_RSA_WITH_3DES_EDE_CBC_SHA 536 TLS_RSA_WITH_RC4_128_MD5 537 TLS_RSA_WITH_RC4_128_SHA 538 TLS_RSA_WITH_AES_128_CBC_SHA 540 In addition, TEAM peers SHOULD support at least one of the following 541 TLS ciphersuites: 543 TLS_RSA_WITH_3DES_EDE_CBC_SHA 544 TLS_RSA_WITH_RC4_128_MD5 545 TLS_RSA_WITH_RC4_128_SHA 546 TLS_RSA_WITH_AES_128_CBC_SHA 548 TLS as described in [RFC5246] supports compression as well as 549 ciphersuite negotiation. Therefore during the TEAM Phase 1 550 conversation the TEAM endpoints MAY request or negotiate TLS 551 compression. 553 If the full TLS handshake is performed, then the first payload of 554 TEAM Phase 2 MAY be sent along with finished handshake message to 555 reduce number of round trips. 557 Since after the TLS session is established, another complete EAP 558 negotiation will occur and the peer will authenticate using a 559 secondary mechanism, with TEAM the client need not authenticate as 560 part of TLS session establishment. 562 Note that since TLS client certificates are sent in the clear, if 563 identity protection is required, then it is possible for the TLS 564 authentication to be re-negotiated after the first server 565 authentication. Alternatively, if identity protection is required, 566 then it is possible to perform certificate authentication using a EAP 567 method (for example: EAP-TLS [RFC5216]) within the TLS session during 568 TEAM Phase 2. 570 To accomplish this, the server will typically not request a 571 certificate in the server_hello, then after the server_finished 572 message is sent, and before TEAM Phase 2 begins, the server MAY send 573 a TLS hello_request. This allows the client to perform client 574 authentication by sending a client_hello if it wants to, or send a 575 no_renegotiation alert to the server indicating that it wants to 576 continue with TEAM Phase 2 instead. Assuming that the client permits 577 renegotiation by sending a client_hello, then the server will respond 578 with server_hello, a certificate and certificate_request messages. 579 The client replies with certificate, client_key_exchange and 580 certificate_verify messages. Since this re-negotiation occurs within 581 the encrypted TLS channel, it does not reveal client certificate 582 details. 584 4.3.3. Session Resumption 586 The purpose of the sessionId within the TLS protocol and the Server- 587 Identifier TLV in TEAM is to allow for improved efficiency in the 588 case where a client repeatedly attempts to authenticate to an EAP 589 server within a short period of time. This capability is 590 particularly useful for support of wireless roaming. 592 In order to help the peer choose a sessionID that belongs to the 593 specific server, the EAP server MAY send an identifier (Server- 594 Identifier TLV) that the peer can use as a hint. The Server- 595 Identifier TLV MAY be sent in the first TEAM packet from the EAP 596 server to the peer. In order to detect modification of the Server- 597 Identifier TLV, the Server-Identifier TLV is included in calculation 598 of the compound MAC. 600 It is left up to the peer whether to attempt to continue a previous 601 session, thus shortening the TEAM Phase 1 conversation. Typically 602 the peer's decision will be made based on the time elapsed since the 603 previous authentication attempt to that EAP server. 605 Based on the sessionId chosen by the peer, and the time elapsed since 606 the previous authentication, the EAP server will decide whether to 607 allow the continuation, or whether to choose a new session. 609 If the EAP server is resuming a previously established session, then 610 it MUST include only a TLS change_cipher_spec message and a TLS 611 finished handshake message after the server_hello message. The 612 finished message contains the EAP server's authentication response to 613 the peer. 615 If the preceding server_hello message sent by the EAP server in the 616 preceding EAP-Request packet indicated the resumption of a previous 617 session, then the peer MUST send only the change_cipher_spec and 618 finished handshake messages. The finished message contains the 619 peer's authentication response to the EAP server. The latter 620 contains the EAP server's authentication response to the peer. The 621 peer will verify the hash in order to authenticate the EAP server. 623 If authentication fails, then the peer and EAP server MUST follow the 624 error handling behavior specified in Section 4.5 626 Even if the session is successfully resumed with the same EAP server, 627 the peer and EAP server MUST NOT assume that either will skip inner 628 EAP methods. The peer may have roamed to a network which may use the 629 same EAP server, but may require conformance with a different 630 authentication policy, and therefore may require inner EAP 631 authentication methods. 633 4.3.4. Version Negotiation 635 TEAM packets contain a three bit version field, which enables TEAM 636 implementations to be backward compatible with previous versions of 637 the protocol. This specification documents version1 of the TEAM 638 protocol; implementations of this specification MUST use a version 639 field set to 1. Version negotiation proceeds as follows: 641 1. In the first EAP-Request sent with EAP-Type=TEAM, the EAP server 642 MUST set the version field to the highest supported version 643 number. 645 2. If the EAP peer supports that version of the protocol, it MUST 646 respond with an EAP-Response of EAP-Type=TEAM, and the version 647 number proposed by the EAP server. 649 3. If the EAP peer does not support that version, it responds with 650 an EAP-Response of EAP-Type=TEAM and the highest supported 651 version number. 653 4. If the TEAM server does not support the version number proposed 654 by the TEAM peer, it either starts a different EAP type or 655 terminates the conversation by sending an EAP-Failure, depending 656 on the server policy. 658 The version negotiation procedure guarantees that the EAP peer and 659 server will agree to the latest version supported by both parties. 660 If version negotiation fails, then use of TEAM will not be possible, 661 and another mutually acceptable EAP method will need to be negotiated 662 if authentication is to proceed. 664 The TEAM version field is not protected by TLS and therefore can be 665 modified in transit. In order to detect modification of the TEAM 666 version which could occur as part of a "downgrade" attack, the peer 667 and EAP server check if the version it sent during negotiation is 668 same as the version claimed to be received by the other party. Each 669 party uses the Crypto-Binding TLV (Section 6.5) to inform the other 670 party of the version number it received during the TEAM version 671 negotiation. The receiver of the Crypto-Binding TLV must verify that 672 the version in the Crypto-Binding TLV matches the version it sent 673 during TEAM version negotiation. 675 4.4. TEAM Phase 2 677 The second part of the TEAM conversation typically consists of a 678 complete EAP conversation occurring within the TLS session negotiated 679 in TEAM Phase 1, ending with protected termination using the Result 680 TLV. TEAM Phase 2 will occur only if establishment of a new TLS 681 session in Phase 1 is successful or a TLS session is successfully 682 resumed in Phase 1. In cases where a new TLS session is established 683 in TEAM Phase 1, the first payload of the Phase 2 conversation MAY be 684 sent by the EAP server along with the finished message to save a 685 round-trip. 687 Phase 2 SHOULD NOT occur if the EAP Server authenticates 688 unsuccessfully, and MUST NOT occur if establishment of the TLS 689 session in Phase 1 was not successful or a TLS fatal error has been 690 sent terminating the conversation. 692 Since all packets sent within the TEAM Phase 2 conversation occur 693 after TLS session establishment, they are protected using the 694 negotiated TLS ciphersuite. All EAP packets of the EAP conversation 695 in Phase 2 including the EAP header of the inner EAP method are 696 protected using the negotiated TLS ciphersuite. 698 Phase 2 may not always include a EAP conversation within the TLS 699 session, referred to in this document as inner EAP methods. However, 700 Phase 2 MUST always end with either protected termination or 701 protected error termination (e.g. TLS alert). 703 Within Phase 2, protected EAP conversation and protected termination 704 packets are always carried within TLVs. There are TLVs defined for 705 specific purposes such as carrying EAP-authentication messages and 706 carrying cryptographic binding information. New TLVs may be 707 developed for other purposes. 709 4.4.1. Protected Conversation 711 Phase 2 of the TEAM conversation typically begins with the EAP server 712 sending an optional EAP-Request/Identity packet to the peer, 713 protected by the TLS ciphersuite negotiated in Phase 1 of TEAM. The 714 peer responds with an EAP-Response/Identity packet to the EAP server, 715 containing the peer's userId. Since this Identity Request/Response 716 exchange is protected by the ciphersuite negotiated in TLS, it is not 717 vulnerable to snooping or packet modification attacks. 719 After the TLS session-protected Identity exchange, the EAP server 720 will then select authentication method(s) for the peer, and will send 721 an EAP-Request with the Type field set to the initial method. As 722 described in [RFC3748], the peer can NAK the suggested EAP method, 723 suggesting an alternative. Since the NAK will be sent within the TLS 724 channel, it is protected from snooping or packet modification. As a 725 result, an attacker snooping on the exchange will be unable to inject 726 NAKs in order to "negotiate down" the authentication method. An 727 attacker will also not be able to determine which EAP method was 728 negotiated. 730 The EAP conversation within the TLS protected session may involve a 731 sequence of zero or more EAP authentication methods; it completes 732 with the protected termination described in Section 4.4.2 Several 733 TLVs may be included in each Request and Response. EAP packets are 734 always encapsulated within EAP Payload TLVs. 736 In a typical EAP conversation, the result of the conversation is 737 communicated by sending EAP Success or EAP Failure packets after the 738 EAP method is complete. The EAP Success or Failure packet is 739 considered the last packet of the EAP conversation; and therefore 740 cannot be used when sequences need to be supported. Hence, instead 741 of using the EAP Success or EAP Failure packet, both peer and EAP 742 server MUST use the Intermediate-Result TLV (Section 6.10) to 743 communicate the result. 745 In a typical EAP conversation, the EAP Success or EAP Failure is 746 considered the last packet of the EAP conversation. Within TEAM, the 747 EAP server can start another EAP method after success or failure of 748 the previous EAP method inside the protected session. 750 In a sequence of more than one EAP authentication method, to make 751 sure the same parties are involved in tunnel establishment and 752 successful completion of previous inner EAP methods, before 753 completing negotiation of the next EAP method, both peer and EAP 754 server MUST use cryptographic binding (Crypto-Binding TLV 755 Section 6.5). 757 The Intermediate-Result TLV is used to indicate the result of a 758 individual successful EAP method, and the Result TLV (Section 6.2) is 759 used to indicate result of the entire TEAM conversation. 761 The Intermediate-Result and Crypto-Binding TLVs MUST be sent after 762 each EAP method that was successful. If the EAP method failed, or if 763 the EAP method negotiation did not complete, then an Intermediate- 764 Result TLV MAY be included, and the Crypto-Binding TLV MUST NOT be 765 included. An exception is that the Crypto-Binding TLV MUST be sent 766 along with a protected success/failure indication (see 767 Section 4.4.2). 769 If these TLVs are not sent after a successful EAP method, it should 770 be considered a tunnel compromise error by peer and EAP server, 771 resulting in the termination of the conversation (as described in 772 Section 4.5). 774 A subsequent EAP conversation can be started after both TLVs are 775 exchanged in a TLV packet. Alternatively, if a subsequent EAP 776 conversation is being attempted, then in order to reduce round trips, 777 both TLVs SHOULD be sent with the EAP-Payload of the first EAP packet 778 of the next EAP conversation (for example, EAP-Identity or EAP packet 779 of the EAP method). Alternatively, if the next packet is the 780 protected success/failure packet, then in order to reduce round 781 trips, both TLVs MUST be sent with the protected success/failure 782 packet. 784 If the EAP server sends a valid Crypto-Binding TLV to the peer, the 785 peer MUST respond with a Crypto-Binding TLV. If the Crypto-Binding 786 TLV is invalid, it should be considered a tunnel compromise error by 787 the peer. If the peer does not respond with a TLV packet containing 788 the Crypto-Binding TLV, it MUST be considered a tunnel compromise 789 error by the EAP server. 791 Within a TEAM part 2 conversation, a peer MAY request the trusted 792 root of a server certificate using a Server-Trusted-Root TLV 793 (Section 6.16), and the EAP server MAY respond with a Server-Trusted- 794 Root TLV to the peer. The Server-Trusted-Root TLV can be exchanged 795 in regular authentication mode or server unauthenticated tunnel 796 provisioning mode. 798 After the peer has determined that it has successfully authenticated 799 the EAP server and determined that the tunnel and inner EAP methods 800 were between the same peer and EAP server by validating the Crypto- 801 Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked 802 as optional) to request the trusted root of server certificate from 803 the EAP server. The peer may receive a response, but is not required 804 to use the trusted root received from the EAP server. 806 If the EAP server has determined that it has successfully 807 authenticated the peer and determined that the tunnel and inner EAP 808 methods were between the same peer and EAP server by validating the 809 Crypto-Binding TLV, then it MAY respond with the the server-trusted- 810 root containing the PCKS#7 TLV (Section 6.17). 812 4.4.2. Protected Termination 814 Phase 2 of the TEAM conversation is completed by the exchange of 815 success/failure indications (Result TLV) within a TLV packet 816 protected by the TLS session. 818 Even if Crypto-Binding TLVs have been exchanged in previous 819 conversations, the Crypto-Binding TLV MUST be included in both 820 protected success/failure (Result TLV) indications. If the TLVs are 821 not included, or if the TLVs are invalid, it should be considered a 822 tunnel compromise error, and the peer and EAP server MUST follow the 823 rules described in Section 4.5 to abort the conversation. 825 The Result TLV is sent within the TLS channel. The TEAM client then 826 replies with a Result TLV. The conversation concludes with the TEAM 827 server sending a cleartext success/failure indication. 829 The only outcome which should be considered as successful 830 authentication is when a Result TLV of Status=Success is answered by 831 the peer with a Result TLV of Status=Success. 833 The combinations (Result TLV=Failure, Result TLV=Success), (Result 834 TLV=Failure, Result TLV=Failure), (no TLVs exchange or no protected 835 success or failure) should be considered an authentication failure by 836 both the peer and EAP server. Once the peer and EAP server consider 837 that authentiation has failed, these are the last packets inside the 838 protected tunnel. These combinations are considered an 839 authentication failure regardless of whether a cleartext EAP Success 840 or EAP Failure packet is subsequently sent. 842 If the EAP server wants authentication to fail, it sends the TLV 843 response with Result TLV=Failure. If the EAP server sends a failure, 844 the peer MUST respond with Result TLV=Failure and the Crypto-Binding 845 TLV, without any other mandatory TLVs. The Crypto-Binding TLV is 846 calculated using the key derivation formula in Section 2.5; if for 847 some reason one or more inner EAP method MSKs were not derived, then 848 these MSKs are assumed to be null. 850 If the EAP server has sent the success indication (Result 851 TLV=Success), the peer is allowed to refuse to accept a Success 852 message from the EAP server since the client's policy may require 853 completion of certain EAP methods or the client may require 854 credentials. 856 If the EAP server has sent a success indication (Result TLV=success), 857 and the peer wants authentication to fail, it sends the TLV response 858 with Result TLV=Failure and Crypto-Binding TLV. 860 After the EAP server returns success, if the peer wants to request 861 the EAP server to continue conversation, it sends a Result 862 TLV=Success along with a Request-Action TLV with the appropriate 863 action (e.g. Negotiate-EAP, or Process-TLV). If the Request-Action 864 TLV is set to mandatory, then the EAP server MUST process the action, 865 or return status=failure, closing the conversation inside the tunnel. 866 If the Request-Action TLV is set to optional, then the EAP server can 867 ignore the TLV and return Result TLV=Success again, closing the 868 conversation inside the tunnel. 870 4.4.3. Provisioning of Credentials 872 TEAM supports built-in provisioning of certificate trust anchors and 873 can be extended to provisioning of other types of credentials. The 874 following two provisioning modes are suported: 876 1. Provisioning inside a server authenticated TLS tunnel 877 2. Provisioning inside a server unauthenticated TLS tunnel 879 4.4.3.1. Provisioning Inside a Server Authenticated TLS Tunnel 881 After regular authentication in TEAM Phase 2, the peer and EAP server 882 can use the Server-Trusted-Root TLV to request and provision peer 883 credentials. The provisioning payload is exchanged after the peer 884 and EAP server have determined that both have successfully 885 authenticated each other (either thru TLS handshake and/or inner EAP 886 method), and the tunnel and inner EAP methods are between the same 887 peers. 889 After the peer has determined that it has successfully authenticated 890 the EAP server and determined that the tunnel and inner EAP methods 891 were between the same peer and EAP server by validating the Crypto- 892 Binding TLV, it MAY send one or more Server- Trusted-Root TLVs 893 (marked as optional) to request credentials from the EAP server. The 894 EAP server will send corresponding credentials in the Server-Trusted- 895 Root TLVs if its internal policy has been satisfied. It may ignore 896 the credential provisioning request or request additional 897 authentication methods if its policy so dictates. The peer may 898 receive a credential, but is not required to use the credentials 899 received from the EAP server. 901 4.4.3.2. Provisioning Inside a Server Unauthenticated TLS Tunnel 903 In some cases, the peer may lack the credentials necessary to 904 authenticate the server in the TLS handshake. At the same time, 905 bootstrapping the information to the peer out of band may be 906 prohibitive from a deployment cost perspective. It can rely on the 907 inner EAP method using existing credentials to authenticate the 908 server. 910 In this provisioning mode, as part of TEAM Phase 1, if the peer does 911 not authenticate, or does not successfully authenticate the EAP 912 server during TLS negotiation, it can decide to go into server 913 unauthenticated tunnel provisioning mode. In a certificate-based TLS 914 handshake, the peer verifies that the EAP server possesses the 915 private key corresponding to the public key contained in the 916 certificate presented by the EAP server. However, the peer does not 917 verify whether the certificate presented by the server chains to a 918 provisioned trust anchor, as the peer may not be configured with a 919 certificate trust anchor required to validate the server certificate. 920 If the peer cannot verify that the server possesses the corresponding 921 private key, or if the certificate presented by the server is 922 unacceptable for any reason other than the lack of an appropriate 923 trust anchor, the peer MUST NOT use this provisioning mode. Assuming 924 that the server demonstrates possession of the private key, the peer 925 continues with establishment of the tunnel (TEAM Phase 2). In a 926 certificate-less TLS handshake the peer and server perform an 927 anonymous exchange. There is no attempt by the peer to verify the 928 server's identity. In both the certificate-based and certificate- 929 less TEAM Phase 1 exchange for the Server Unauthenticated mode, it is 930 possible that the TLS channel (TEAM Phase 2) may be terminated by an 931 attacker. For this reason the TEAM Phase 2 exchange MUST be 932 resistant to dictionary attack. 934 The TEAM Phase 2 conversation is unchanged in this mode, except that 935 the peer will only accept an EAP method supporting mutual 936 authentication, key derivation and resistance to dictionary attack 937 that is compatible with its initial credentials (such as EAP-pwd 938 [RFC5931]). The peer then uses the Crypto-Binding TLV to validate 939 that the same server terminates both the TLS channel and the 940 successfully completed EAP method, thereby verifying that the 941 exchange was not subject to a man-in-the-middle attack. Assuming 942 that the Crypto- Binding TLV exchange is successful, the peer will 943 request and the server will subsequently provide a trusted root, 944 using the Server-Trusted-Root TLV. 946 Once the initial provisioning exchange completes, the peer is 947 expected to use the provisioned credentials in subsequent TEAM 948 authentications, and SHOULD NOT continue to use this provisioning 949 mode. 951 TEAM servers and peers implementing this provisioning mode MUST 952 support EAP-pwd [RFC5931] as a TEAM Phase 2 conversation. 954 TEAM servers implementing this provisioning mode MUST support the 955 following additional ciphersuites, beyond those specified in 956 Section 4.3.2: 958 TLS_DH_anon_WITH_AES_128_CBC_SHA 960 TEAM peers implementing this provisioning mode MAY support the 961 following additional ciphersuites, beyond those specified in 962 Section 4.3.2: 964 TLS_DH_anon_WITH_AES_128_CBC_SHA 966 4.5. Error Handling 968 TEAM does not have its own error message capabilities since: 970 1. TLS errors are communicated via TLS alert messages. 971 2. Errors within the EAP conversation in TEAM Phase 2 are expected 972 to be handled by individual EAP methods. 973 3. Violation of the TLV rules (Section 6.19) for inner-TLVs are 974 handled using Result-TLVs together with the Error-Code TLV. 976 If an error occurs at any point in the TLS layer, the EAP server 977 SHOULD send a TLS alert message instead of the next EAP-request 978 packet to the peer. The EAP server SHOULD send an EAP-Request packet 979 with EAP-Type=TEAM, encapsulating a TLS record containing the 980 appropriate TLS alert message. The EAP server SHOULD send a TLS 981 alert message rather than immediately terminating the conversation so 982 as to allow the peer to inform the user of the cause of the failure 983 and possibly allow for a restart of the conversation. To ensure that 984 the peer receives the TLS alert message, the EAP server MUST wait for 985 the peer to reply with an EAP-Response packet. 987 The EAP-Response packet sent by the peer MAY encapsulate a TLS 988 client_hello handshake message, in which case the EAP server MAY 989 allow the TEAM conversation to be restarted, or it MAY contain an 990 EAP-Response packet with EAP-Type=TEAM and no data, in which case the 991 TEAM server MUST send an EAP-Failure packet, and terminate the 992 conversation. 994 It is up to the EAP server whether to allow restarts, and if so, how 995 many times the conversation can be restarted. An EAP server 996 implementing restart capability SHOULD impose a limit on the number 997 of restarts, so as to protect against denial of service attacks. 999 If an error occurs at any point in the TLS layer, the peer SHOULD 1000 send a TLS alert message instead of the next EAP-response packet to 1001 the EAP server. The peer SHOULD send an EAP-Response packet with 1002 EAP-Type=TEAM, encapsulating a TLS record containing the appropriate 1003 TLS alert message. The EAP server may restart the conversation by 1004 sending a EAP-Request packet encapsulating the TLS 1005 hello_request_handshake message, in which case the peer MAY allow the 1006 TEAM conversation to be restarted; or the EAP server can response 1007 with EAP Failure. 1009 Any time the peer or the EAP server finds an error when processing 1010 the sequence of exchanges, such as a violation of the TLV rules 1011 Section 6.19, it should send a Result TLV of failure and Error-Code 1012 TLV=Unexpected_TLVs_Exchanged (a Fatal error), and terminate the 1013 tunnel. This is usually due to an implementation problem and is 1014 considered an fatal error. The party that receives the Error-Code 1015 TLV=Unexpected_TLVs_Exchanged should terminate the tunnel. 1017 If a tunnel compromise error (see (Section 4.4)) is detected by the 1018 Peer or EAP server, the party SHOULD send a Result TLV of failure 1019 without a Crypto-Binding TLV, and Error-Code TLV=Tunnel-compromise- 1020 error (a Fatal error), and terminate the tunnel. The party that 1021 receives the Error-Code TLV=Tunnel-compromise error should terminate 1022 the tunnel. 1024 4.6. Fragmentation and Reassembly 1026 A single TLS record may be up to 16384 octets in length, but a TLS 1027 message may span multiple TLS records, and a TLS certificate message 1028 may in principle be as long as 16MB. 1030 The group of TEAM messages sent in a single round may thus be larger 1031 than the PPP MTU size, the maximum RADIUS packet size of 4096 octets, 1032 or even the Multilink Maximum Received Reconstructed Unit (MRRU). 1034 As described in [RFC1990], the multilink MRRU is negotiated via the 1035 Multilink MRRU LCP option, which includes an MRRU length field of two 1036 octets, and thus can support MRRUs as large as 64 KB. 1038 However, note that in order to protect against reassembly lockup and 1039 denial of service attacks, it may be desirable for an implementation 1040 to set a maximum size for one such group of TLS messages. Since a 1041 typical certificate chain is rarely longer than a few thousand 1042 octets, and no other field is likely to be anywhere near as long, a 1043 reasonable choice of maximum acceptable message length might be 64 1044 KB. 1046 If this value is chosen, then fragmentation can be handled via the 1047 multilink PPP fragmentation mechanisms described in [RFC1990]. this 1048 is desirable, EAP methods are used in other applications such as 1049 [IEEE.802-11.2007] and there may be cases in which multilink or the 1050 MRRU LCP option cannot be negotiated. As a result, a TEAM 1051 implementation MUST provide its own support for fragmentation and 1052 reassembly. 1054 Since EAP is an ACK-NAK protocol, fragmentation support can be added 1055 in a simple manner. In EAP, fragments that are lost or damaged in 1056 transit will be retransmitted, and since sequencing information is 1057 provided by the Identifier field in EAP, there is no need for a 1058 fragment offset field as is provided in IPv4. 1060 TEAM fragmentation support is provided through addition of flag bits 1061 within the EAP-Response and EAP-Request packets, as well as a TLV 1062 Message Length field of four octets. Flags include the Length 1063 included (L), More fragments (M), and TEAM Start (S) bits. The L 1064 flag is set to indicate the presence of the four octet TLV Message 1065 Length field, and MUST be set only for the first fragment of a 1066 fragmented TLV message or set of messages. 1068 The TLV Message Length field in the TEAM header is not protected, and 1069 hence can be modified by a attacker. The TLS record length in the 1070 TLS data is protected. Hence, if the TLV Message length received in 1071 the first packet (with L bit set) is greater or less than the total 1072 size of TLS messages received including multiple fragments, then the 1073 TLV message length should be ignored. 1075 In order to protect against reassembly lockup and denial of service 1076 attacks, it may be desirable for an implementation to set a maximum 1077 size for a single group of Outer-TLV messages. Since a typical 1078 certificate chain is rarely longer than a few thousand octets, and no 1079 other field is likely to be anywhere near as long, a reasonable 1080 choice of maximum acceptable message length for all the Outer-TLVs in 1081 a group of messages might be 64 KB. 1083 The M flag is set on all but the last fragment. The S flag is set 1084 only within the TEAM start message sent from the EAP server to the 1085 peer. The TLV Message Length field is four octets, and provides the 1086 total length of the TLV message or set of messages that is being 1087 fragmented; this simplifies buffer allocation. 1089 When a peer receives an EAP-Request packet with the M bit set, it 1090 MUST respond with an EAP-Response with EAP-Type=TEAM and no data. 1091 This serves as a fragment ACK. The EAP server MUST wait until it 1092 receives the EAP-Response before sending another fragment. In order 1093 to prevent errors in processing of fragments, the EAP server MUST 1094 increment the Identifier field for each fragment contained within an 1095 EAP-Request, and the peer MUST include this Identifier value in the 1096 fragment ACK contained within the EAP-Response. Retransmitted 1097 fragments will contain the same Identifier value. 1099 Similarly, when the EAP server receives an EAP-Response with the M 1100 bit set, it MUST respond with an EAP-Request with EAP-Type=TEAM and 1101 no TLS data. This serves as a fragment ACK. The EAP peer MUST wait 1102 until it receives the EAP-Request before sending another fragment. 1103 In order to prevent errors in the processing of fragments, the EAP 1104 server MUST increment the Identifier value for each fragment ACK 1105 contained within an EAP-Request, and the peer MUST include this 1106 Identifier value in the subsequent fragment contained within an EAP- 1107 Response. 1109 4.7. Key Derivation 1111 Since the normal TLS keys are used in the handshake, and therefore 1112 should not be used in a different context, new keys must be derived 1113 from the TLS master secret to protect the conversation within the 1114 TEAM tunnel. 1116 Instead of deriving keys specific to link layer ciphersuites, EAP 1117 methods provide a Master Session Key (MSK) used to derive keys in a 1118 link layer specific manner. The method used to extract ciphering 1119 keys from the MSK is beyond the scope of this document. 1121 TEAM also derives an Extended Master Session Key (EMSK) which is 1122 reserved for use in deriving keys in other ciphering applications. 1123 This draft also does not discuss the format of the attributes used to 1124 communicate the master session keys from the backend authentication 1125 server to the NAS; examples of such attributes are provided in 1126 [RFC2548]. 1128 TEAM combines key material from the TLS exchange with key material 1129 from inner key generating EAP methods to provide stronger keys and to 1130 bind inner authentication mechanisms to the TLS tunnel. Both the 1131 peer and EAP server MUST derive compound MAC and compound session 1132 keys using the procedure described below. 1134 The input for the cryptographic binding includes the following: 1136 1. The TEAM tunnel key (TK) is calculated using the first 40 octets 1137 of the (secret) key material generated as described in the EAP- 1138 TLS algorithm (see Section 2.3 of [RFC5216]) More explicitly, the 1139 TK is the first 40 octets of the PRF as defined in RFC 5216: 1141 Key_Material = TLS-PRF-128( master_secret, "client EAP 1142 encryption", client.random || 1143 server.random ) 1145 2. The first 32 octets of the MSK provided by each successful inner 1146 EAP method for each successful EAP method completed within the 1147 tunnel. 1149 ISK1..ISKn are the MSK portion of the EAP keying material 1150 obtained from methods 1 to n. The ISKj SHALL be the first 32 1151 octets of the generated MSK of the jth EAP method. If the MSK 1152 length is less than 32 octets, it SHALL be padded with 0x00's to 1153 ensure the MSK is 32 octets. Similarly, if no keying material is 1154 provided for the EAP method, then ISKj SHALL be set to zero (e.g. 1155 32 octets of 0x00). 1157 The key derivation process is based on "extract-then-expand" 1158 technique of HKDF [RFC5869]. Entropy from the TEAM Tunnel Key, TK, 1159 is first extracted into a pseudo-random key and then expanded into a 1160 series of intermediate combined keys, IPMK1..IPMKn, and Compound MAC 1161 keys, CMK1..CMKn. 1163 IPMK0 = HKDF-Extract(salt, TK) 1164 for j = 1 to n do 1165 IPMKj | CMKj = HKDF-Expand(IPMK(j-1), 1166 "Inner Methods Compound Keys" | ISKj, 1167 60) 1168 done 1170 Where: 1171 o salt is 32 octets of 0x00 1172 o IPMKj are 40 octets in length 1173 o CMKj are 20 octets in length used to generate the intermediate 1174 Compound MACs 1175 and 1176 o n = the last successful EAP method inside the tunnel at the point 1177 where the Compound Session Key is derived 1179 4.7.1. Compound Session Key Derivation 1181 The compound session key (CSK) is derived on both the peer and EAP 1182 server: 1184 CSK = HKDF-Expand(IPMKn, "Session Key Generating Function", 128) 1186 The length of the CSK MUST be 128 octets. The first 64 octets SHALL 1187 be taken as the MSK and the second 64 octets SHALL be taken as the 1188 EMSK. The MSK and EMSK are described in [RFC3748]. 1190 4.8. Ciphersuite Negotiation 1192 Since TLS supports TLS ciphersuite negotiation, peers completing the 1193 TLS negotiation will also have selected a TLS ciphersuite, which 1194 includes key strength, encryption and hashing methods. However, 1195 unlike in [RFC5216], within TEAM, the negotiated TLS ciphersuite 1196 relates only to the mechanism by which the TEAM Phase 2 conversation 1197 will be protected, and has no relationship to link layer security 1198 mechanisms negotiated within the PPP Encryption Control Protocol 1199 (ECP) [RFC1968] or within IEEE 802.11 [IEEE.802-11.2007]. 1201 As a result, this specification currently does not support secure 1202 negotiation of link layer ciphersuites. 1204 5. TEAM Protocol Description 1206 5.1. TEAM Protocol Layers 1208 TEAM packets may include TLVs both inside and outside the TLS tunnel. 1209 The term "Outer TLVs" is used to refer to optional TLVs outside the 1210 TLS tunnel, which are only allowed in the first two messages in the 1211 TEAM protocol, i.e., the first EAP server to peer message and first 1212 peer to EAP server message. If the message is fragmented, the whole 1213 set of messages is counted as one message. The term "Inner TLVs" is 1214 used to refer to TLVs sent within the TLS tunnel. 1216 In TEAM Phase 1, Outer TLVs are used to help establishing the TLS 1217 tunnel, but no Inner TLVs are used. Therefore the layering of TEAM 1218 Phase 1 is as follows: 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | TLS | Optional Outer TLVs | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | TEAM | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | EAP | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 In Phase 2 of the TEAM conversation, TLS records may encapsulate zero 1229 or more Inner TLVs, but no Outer TLVs. EAP packets (including EAP 1230 header fields) used within tunneled EAP authentication methods are 1231 carried within Inner TLVs. Therefore the layering of TEAM Phase 2 is 1232 as follows: 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | EAP | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Inner-TLVs (EAP-Payload TLV) | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | TLS | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | TEAM | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | EAP | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 5.2. TEAM Packet Format 1248 A summary of the TEAM packet format is shown below. The fields are 1249 transmitted from left to right. 1251 0 1 2 3 1252 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 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Code | Identifier | Length | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Type | Flags | Ver | Fragment Message Length 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Fragment Message Length | TLS Message Length 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | TLS Message Length | TLS Data... 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Outer TLVs... 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 Code 1267 1 - Request 1268 2 - Response 1270 Identifier 1272 The Identifier field is one octet and aids in matching responses 1273 with requests. The Identifier field MUST be changed on each 1274 Request packet. The Identifier field in a Response packet MUST 1275 match the Identifier field from the corresponding Request. 1277 Length 1279 The Length field is two octets and indicates the length of the EAP 1280 packet including the Code, Identifier, Length, Type, Flags, 1281 Version, Fragmented Length, TLS Message Length, TLS Data, and 1282 Outer-TLV fields. Octets outside the range of the Length field 1283 should be treated as Data Link Layer padding and should be ignored 1284 on reception. 1286 Type 1288 - TEAM 1290 Flags 1292 0 1 2 3 4 1293 +-+-+-+-+-+ 1294 |L M S T R| 1295 +-+-+-+-+-+ 1297 L = Length included 1298 M = More fragments 1299 S = TEAM start 1300 T = TLS length included 1301 R = Reserved (must be zero) 1303 The L bit (Fragmented Message Length included) is set to indicate 1304 the presence of the four octet Fragmented Message Length field, 1305 and MUST be set for the first fragment of a fragmented TEAM 1306 message or set of messages. The M bit (more fragments) is set on 1307 all but the last fragment. The S bit (TEAM start) is set in a 1308 TEAM Start message. This differentiates the TEAM Start message 1309 from a fragment acknowledgment. The T bit (TLS Message Length 1310 included) is set to indicate the presence of the four octet TLS 1311 Message Length field, and MUST only be set for packet that 1312 contains Outer-TLVs. It can be used to calculate the start of the 1313 Outer-TLVs. 1315 Version 1317 0 1 2 1318 +-+-+-+ 1319 |R|0|1| 1320 +-+-+-+ 1322 R = Reserved (must be zero) 1324 Fragmented Message Length 1326 The Fragmented Message Length field is four octets, and is present 1327 only if the L bit is set. This field provides the total length of 1328 the data after the Fragmented Message Length field in the TEAM 1329 message or set of messages that is being fragmented. 1331 TLS Message Length 1333 The TLS Message Length field is four octets, and is present only 1334 if the T bit is set. This field provides the total length of the 1335 TLS Data in the TEAM message. Data after this length of TLS data 1336 are the Outer TLVs. 1338 TLS Data 1340 The TLS data consists of the encapsulated packet in TLS record 1341 format. 1343 Outer TLVs 1345 The Outer TLVs consist of the optional data used to help 1346 establishing the TLS tunnel in TLV format. The start of the 1347 Outer-TLVs can be derived from the EAP Length field and TLS Length 1348 field. 1350 6. Type-Length-Value Tuples 1352 The TLVs used within TEAM are standard Type-Length-Value (TLV) 1353 objects. The TLV objects could be used to carry arbitrary parameters 1354 between EAP peer and EAP server. Possible uses for TLV objects 1355 include: language and character set for Notification messages and 1356 cryptographic binding. 1358 The EAP peer may not necessarily implement all the TLVs supported by 1359 the EAP server; and hence to allow for interoperability, TLVs allow 1360 an EAP server to discover if a TLV is supported by the EAP peer, 1361 using the NAK TLV. The TEAM packet does not have to contain any 1362 TLVs, nor need it contain any mandatory TLVs. 1364 The mandatory bit in a TLV indicates whether support of the TLV is 1365 required. If the peer or server does not support the TLV, it MUST 1366 send a NAK TLV in response, and all the other TLVs in the message 1367 MUST be ignored. If an EAP peer or server finds an unsupported TLV 1368 which is marked as optional, it can ignore the unsupported TLV. It 1369 MUST NOT send an NAK TLV. 1371 Note that a peer or server may support a TLV with the mandatory bit 1372 set, but may not understand the contents. The appropriate response 1373 to a supported TLV with content that is not understood is defined by 1374 the TLV specification. 1376 Outer-TLVs SHOULD NOT be included in messages after the first two 1377 Outer-TLV messages sent by the peer and EAP server respectively. A 1378 single Outer-TLV message may be fragmented in multiple TEAM packets. 1380 All Outer-TLVs MUST NOT have the mandatory bit set. If an Outer-TLV 1381 has the mandatory bit set, then the packet MUST be ignored. 1383 TEAM implementations MUST support TLVs, as well as processing of 1384 mandatory/optional settings on the TLV. 1386 6.1. TLV Format 1388 TLVs are defined as described below. The fields are transmitted from 1389 left to right. 1391 0 1 2 3 1392 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 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 |M|R| TLV Type | Length | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Value... 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 M 1401 0 - Optional TLV 1402 1 - Mandatory TLV 1404 R 1406 Reserved, set to zero (0) 1408 TLV Type 1410 A 14-bit field, denoting the TLV type. Allocated types include: 1412 1 - Result 1413 2 - NAK 1414 3 - Error-Code 1415 4 - Connection-Binding 1416 5 - Vendor-Specific 1417 6 - URI 1418 7 - EAP-Payload 1419 8 - Intermediate-Result 1420 9 - Crypto-Binding 1421 10 - Calling-Station-Id 1422 11 - Called-Station-Id 1423 12 - NAS-Port-Type 1424 13 - Server-Identifier 1425 14 - Identity-Type 1426 15 - Server-Trusted-Root 1427 16 - Request-Action 1428 17 - PKCS#7 1430 Length 1432 The length of the Value field in octets 1434 Value 1436 The value of the TLV 1438 6.2. Result TLV 1440 The Result TLV provides support for acknowledged success and failure 1441 messages within TEAM. TEAM implementations MUST support this TLV, 1442 which cannot be responded to with a NAK TLV. If the Status field 1443 does not contain one of the known values, then the peer or EAP server 1444 MUST drop the connection. The Result TLV is defined as follows: 1446 0 1 2 3 1447 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 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 |M|R| TLV Type | Length | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Status | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 M 1456 1 (Mandatory) 1458 R 1460 0 1462 TLV Type 1464 1 for Result 1466 Length 1468 2 1470 Status 1472 The Status field is two octets. Values include: 1474 1 - Success 1475 2 - Failure 1477 6.3. NAK TLV 1479 The NAK TLV allows a peer to detect TLVs that are not supported by 1480 the other peer. A TLV packet can contain 0 or more NAK TLVs. TEAM 1481 implementations MUST support the NAK TLV, which cannot be responded 1482 to with a NAK TLV. The NAK TLV is defined as follows: 1484 0 1 2 3 1485 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 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 |M|R| TLV Type | Length | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Vendor-Id | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | NAK-Type | TLVs.... 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 M 1496 1 (Mandatory) 1498 R 1500 0 1502 TLV Type 1504 2 for NAK 1506 Length 1508 >= 6 1510 Vendor-ID 1512 The Vendor-Id field is four octets, and contains the Vendor-Id of 1513 the TLV that was not supported. The high-order octet is 0 and the 1514 low-order 3 octets are the SMI Network Management Private 1515 Enterprise Code of the Vendor in network byte order. The Vendor- 1516 Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. 1517 For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI 1518 code. 1520 NAK-Type 1522 The NAK-Type field is two octets. The field contains the Type of 1523 the TLV that was not supported. A TLV of this Type MUST have been 1524 included in the previous packet. 1526 TLVs 1528 This field contains a list of TLVs, each of which MUST NOT have 1529 the mandatory bit set. These optional TLVs can be used in the 1530 future to communicate why the offending TLV was determined to be 1531 unsupported. 1533 6.4. Error-Code TLV 1535 The Error-Code TLV allows a TEAM peer or server to indicate errors to 1536 the other party. A TLV packet can contain 0 or more Error TLVs. 1537 Error-Code TLVs MUST be marked as Mandatory. TEAM implementations 1538 MUST support the Error-Code TLV, which cannot be responded to with a 1539 NAK TLV. The Error-Code TLV is defined as follows: 1541 0 1 2 3 1542 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 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 |M|R| TLV Type | Length | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Error-Code | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 M 1551 1 (Mandatory) 1553 R 1555 0 1557 TLV Type 1559 3 for Error-Code 1561 Length 1563 4 1565 Error-Code 1567 The Error-Code field is four octets. Error Codes 1-999 represent 1568 successful outcomes (informative messages), 1000-1999 represent 1569 warnings, and codes 2000-2999 represent fatal errors. If an 1570 Error- Code TLV with a fatal error has been sent, then the 1571 conversation must be terminated. 1573 Currently defined values for Error-Code include: 1575 2001 - Tunnel_Compromise_Error 1576 2002 - Unexpected_TLVs_Exchanged 1578 6.5. Crypto-Binding TLV 1580 The Crypto-Binding TLV is used prove that both peers participated in 1581 the sequence of authentications (specifically the TLS session and 1582 inner EAP methods that generate keys). 1584 Both the Binding Request (B1) and Binding Response (B2) use the same 1585 packet format. However the Sub-Type indicates whether it is B1 or 1586 B2. 1588 The Crypto-Binding TLV MUST be used to perform Cryptographic Binding 1589 after each successful EAP method in a sequence of EAP methods is 1590 complete in TEAM Phase 2. The Crypto-Binding TLV can also be used 1591 during Protected Termination. 1593 The Crypto-Binding TLV must have the version number received during 1594 the TEAM version negotiation. The receiver of the Crypto-Binding TLV 1595 must verify that the version in the Crypto-Binding TLV matches the 1596 version it sent during the TEAM version negotiation. If this check 1597 fails then the TLV is invalid. 1599 The receiver of the Crypto-Binding TLV must verify that the subtype 1600 is not set to any value other than the ones allowed. If this check 1601 fails then the TLV is invalid. 1603 This message format is used for the Binding Request (B1) and also the 1604 Binding Response. This uses TLV type CRYPTO_BINDING_TLV. TEAM 1605 implementations MUST support this TLV and this TLV cannot be 1606 responded to with a NAK TLV. The Crypto-Binding TLV is defined as 1607 follows: 1609 0 1 2 3 1610 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 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 |M|R| TLV Type | Length | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Reserved | Version | Received Ver. | Sub-Type | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | | 1617 ~ Nonce ~ 1618 | | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | | 1621 ~ Compound MAC ~ 1622 | | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 M 1627 1 (Mandatory) 1629 R 1631 0 1633 TLV Type 1635 9 for Crypto-Binding 1637 Length 1639 56 1641 Reserved 1643 Reserved, set to zero (0) 1645 Version 1647 The Version field is a single octet, which is set to the version 1648 of Crypto-Binding TLV. For the Crypto-Binding TLV defined in this 1649 specification, it is set to one (1). 1651 Sub-Type 1653 The Sub-Type field is two octets. Possible values include: 1655 0 - Binding Request 1656 1 - Binding Response 1658 Nonce 1660 The Nonce field is 32 octets. It contains a 256 bit nonce that is 1661 temporally unique, used for compound MAC key derivation at each 1662 end. This is the S_NONCE for the B1 message and a C_NONCE for the 1663 B2 message. 1665 Compound MAC 1667 The Compound MAC field is 20 octets. This can be the Server MAC 1668 (B1_MAC) or the Client MAC (B2_MAC). It is computed using the 1669 HMAC-SHA1-160 keyed MAC that provides 160 bits of output using the 1670 CMK key. The MAC is computed over the buffer created after 1671 concatenating these fields in the following order: 1673 1. The entire Crypto-Binding TLV attribute with the MAC field 1674 zeroed out 1675 2. The EAP Type sent by the other party in the first TEAM message 1676 3. All the Outer-TLVs from the first TEAM message sent by EAP 1677 server to peer. If a single TEAM message is fragmented into 1678 multiple TEAM packets; then the Outer-TLVs in all the 1679 fragments of that message MUST be included. 1680 4. All the Outer-TLVs from the first TEAM message sent by the 1681 peer to the EAP server. If a single TEAM message is 1682 fragmented into multiple TEAM packets, then the Outer-TLVs in 1683 all the fragments of that message MUST be included. 1685 6.6. Connection-Binding TLV 1687 The Connection-Binding TLV allows for connection specific information 1688 to be sent by the peer to the AAA server. This TLV should be logged 1689 by the EAP or AAA server. The AAA or EAP server should not deny 1690 access if there is a mismatch between the value sent through the AAA 1691 protocol and this TLV. 1693 The format of this TLV is defined for the layer that defines the 1694 parameters. The format of the value sent by the peer to the EAP 1695 server may be different from the format of the corresponding value 1696 sent through the AAA protocol. For example, the connection binding 1697 TLV may contain the 802.11 MAC Address or SSID [IEEE.802-11.2007]. 1699 TEAM implementations MAY support this TLV and this TLV MUST NOT be 1700 responded to with a NAK TLV. The Connection-Binding TLV is defined 1701 as follows: 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 |M|R| TLV Type | Length | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | TLVs... 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 M 1713 0 (Optional) 1715 R 1717 0 1719 TLV Type 1721 4 for Connection-Binding 1723 Length 1725 >= 0 1727 TLVs 1729 The field contains a list of TLVs, each in the same format defined 1730 in Section 6.1, with the Mandatory flag bit cleared (0). These 1731 TLVs contain information on the identity of the peer and 1732 authenticator (layer 2 or IP addresses); the media used to connect 1733 the peer and authenticator (NAS-Port-Type); and/or the service the 1734 client is trying to access on the gateway (SSID). See 1735 Section 6.19.4 for further information. 1737 6.7. Vendor-Specific TLV 1739 The Vendor-Specific TLV is available to allow vendors to support 1740 their own extended attributes not suitable for general usage. 1742 A Vendor-Specific-TLV can contain one or more TLVs, referred to as 1743 Vendor TLVs. The TLV-type of the Vendor-TLV will be defined by the 1744 vendor. All the Vendor TLVs inside a single Vendor- Specific TLV 1745 belong to the same vendor. 1747 TEAM implementations MUST support the Vendor-Specific TLV, and this 1748 TLV MUST NOT be responded to with a NAK TLV. If a TEAM 1749 implementation does not support one or more of the Vendor TLVs inside 1750 in the Vendor-Specific TLV it SHOULD respond to the Vendor TLV(s) 1751 with NAK TLV(s) containing the appropriate Vendor-ID and Vendor-TLV 1752 type. 1754 Vendor TLVs may be optional or mandatory. Vendor TLVs sent in the 1755 protected success and failure packets MUST be marked as optional. If 1756 Vendor TLVs sent in protected success/failure packets are marked as 1757 Mandatory, then the peer or EAP server MUST drop the connection. 1759 The Vendor-Specific TLV is defined as follows: 1761 0 1 2 3 1762 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 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 |M|R| TLV Type | Length | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | Vendor-Id | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Vendor TLVs.... 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 M 1773 1 (Mandatory) 1775 R 1777 0 1779 TLV Type 1781 5 for Vendor-Specific 1783 Length 1785 >= 4 1787 Vendor-ID 1789 The Vendor-Id field is four octets, and contains the Vendor-Id of 1790 the TLV that was not supported. The high-order octet is 0 and the 1791 low-order 3 octets are the SMI Network Management Private 1792 Enterprise Code of the Vendor in network byte order. The Vendor- 1793 Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. 1794 For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI 1795 code. 1797 Vendor TLVs 1799 This field is of indefinite length. It contains vendor- 1800 specificTLVs, in a format defined by the vendor. 1802 6.8. URI TLV 1804 The URI TLV allows a server to send a URI to the client to refer it 1805 to a resource. The TLV contains a URI in the format specified in RFC 1806 3986 [RFC3986] with UTF-8 encoding. Interpretation of the value of 1807 the URI is outside the scope of this document. 1809 If a packet contains multiple URI TLVs, then the client SHOULD select 1810 the first TLV it can implement, and ignore the others. If the client 1811 is unable to implement any of the URI TLVs, then it MAY ignore the 1812 error. TEAM implementations MAY support this TLV; and this TLV 1813 cannot be responded to with a NAK TLV. The URI TLV is defined as 1814 follows: 1816 0 1 2 3 1817 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 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 |M|R| TLV Type | Length | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | URI 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 M 1826 0 (Optional) 1828 R 1830 0 1832 TLV Type 1834 6 for URI 1836 Length 1838 >= 0 1840 URI 1842 This field is of indefinite length, and conforms to the format 1843 specified in RFC 3986. 1845 6.9. EAP-Payload TLV 1847 To allow piggybacking EAP request and response with other TLVs, the 1848 EAP Payload TLV is defined, which includes an encapsulated EAP packet 1849 and 0 or more TLVs. TEAM implementations MUST support this TLV, 1850 which cannot be responded to with a NAK TLV. The EAP-Payload TLV is 1851 defined as follows: 1853 0 1 2 3 1854 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 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 |M|R| TLV Type | Length | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | EAP-Packet... 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | TLVs... 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 M 1865 1 (Mandatory) 1867 R 1869 0 1871 TLV Type 1873 7 for EAP-Payload 1875 Length 1877 >= 0 1879 EAP-Packet 1881 This field contains a complete EAP packet, including the EAP 1882 header (Code, Identifier, Length, Type) fields. The length of 1883 this field is determined by the Length field of the encapsulated 1884 EAP packet. 1886 TLVs 1888 This (optional) field contains a list of TLVs associated with the 1889 EAP-Packet field (see Section 6.19.3). The TLVs utilize the same 1890 format described Section 6.1, and MUST NOT have the mandatory bit 1891 set. The total length of this field is equal to the Length field 1892 of the EAP- Payload-TLV, minus the Length field in the EAP header 1893 of the EAP packet field. 1895 6.10. Intermediate-Result TLV 1897 The Intermediate-Result TLV provides support for acknowledged 1898 intermediate Success and Failure messages within EAP. TEAM 1899 implementations MUST support this TLV, which cannot be responded to 1900 with a NAK TLV. The Intermediate-Result TLV is defined as follows: 1902 0 1 2 3 1903 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 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 |M|R| TLV Type | Length | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Status | TLVs... 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 M 1912 1 (Mandatory) 1914 R 1916 0 1918 TLV Type 1920 8 for Intermediate-Result 1922 Length 1924 >= 2 1926 Status 1928 The Status field is two octets. Values include: 1930 1 - Success 1931 2 - Failure 1933 TLVs 1935 This (optional) field contains a list of TLVs associated with the 1936 Intermediate-Result TLV. The TLVs utilize the same format 1937 described Section 6.1, and MUST NOT have the mandatory bit set. 1939 6.11. Calling-Station-Id TLV 1941 This TLV allows a peer to send information to EAP server about the 1942 call originator. This TLV MAY be included in the Connection-Binding- 1943 TLV. 1945 For dial-up, the Called-Station-ID TLV contains the phone number of 1946 the peer. For use with IEEE 802.1X, the MAC address of the peer is 1947 included [RFC3580]. 1949 For VPN, this attribute is used to send the IPv4 or IPV6 address of 1950 the interface of the peer used to initiate the VPN in ASCII format. 1951 Where the Fully Qualified Domain Name (FQDN) of the VPN client is 1952 known, it SHOULD be appended, separated from the address with a " " 1953 (space). Example: "12.20.2.3 vpnserver.example.com". 1955 As described in Section 7.15 of [RFC3748], this TLV SHOULD be logged 1956 by the EAP or AAA server, and MAY be used for comparison with 1957 information gathered by other means. 1959 However, since the format of this TLV may not match the format of the 1960 information gathered by other means, if an EAP server or AAA server 1961 supports the capability to deny access based on a mismatch, spurious 1962 authentication failures may occur. As a result, implementations 1963 SHOULD allow the administrator to disable this check. 1965 TEAM implementations MAY support this TLV and this TLV MUST NOT be 1966 responded to with a NAK TLV. The Calling-Station-ID TLV is defined 1967 as follows: 1969 0 1 2 3 1970 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 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 |M|R| TLV Type | Length | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | String... 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 M 1979 0 (Optional) 1981 R 1983 0 1985 TLV Type 1987 10 for Calling-Station-Id 1989 Length 1991 >= 0 1993 String 1995 The field should be the same as the value of the 1996 Calling-Station-ID attribute in [RFC2865]. 1998 6.12. Called-Station-Id TLV 2000 This TLV allows a peer to send information to EAP server about the 2001 NAS it called. This TLV MAY be included in the Connection-Binding 2002 TLV. 2004 For dial-up, the Calling-Station-ID TLV contains the phone number 2005 called by the peer. For use with IEEE 802.1X, the MAC address of the 2006 NAS is included, as specified in [RFC3580]. 2008 For VPN, this attribute is used to send the IPv4 or IPv6 address of 2009 VPN server in ASCII format. Where the Fully Qualified Domain Name 2010 (FQDN) of the VPN server is known, it SHOULD be appended, separated 2011 from the address with a " " (space). Example: "12.20.2.3 2012 vpnserver.example.com". 2014 This TLV SHOULD be logged by the EAP or AAA server, and MAY be used 2015 for comparison with information gathered by other means. However, 2016 since the format of this TLV may not match the format of the 2017 information gathered by other means, if an EAP server or AAA server 2018 supports the capability to deny access based on a mismatch, spurious 2019 authentication failures may occur. As a result, implementations 2020 SHOULD allow the administrator to disable this check. 2022 TEAM implementations MAY support this TLV, and this TLV MUST NOT be 2023 responded to with a NAK TLV. The Called-Station-ID TLV is defined as 2024 follows: 2026 0 1 2 3 2027 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 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 |M|R| TLV Type | Length | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | String... 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 M 2036 0 (Optional) 2038 R 2040 0 2042 TLV Type 2044 11 for Called-Station-Id 2046 Length 2048 >= 0 2050 String 2052 The field should be the same as the value of the Called-Station-ID 2053 attribute in [RFC2865]. 2055 6.13. NAS-Port-Type TLV 2057 This TLV allows a peer to send information to EAP server about the 2058 type of physical connection used by the peer to connect to NAS. This 2059 TLV MAY be included in the Connection-Binding-TLV. 2061 The value of this field is the same as the value of NAS-Port-Type 2062 attribute in [RFC2865]. 2064 This TLV SHOULD be logged by the EAP or AAA server and MAY be used 2065 for comparison with information gathered by other means. However, 2066 since the format of this TLV may not match the format of the 2067 information gathered by other means, if an EAP server or AAA server 2068 supports the capability to deny access based on a mismatch, spurious 2069 authentication failures may occur. As a result, implementations 2070 SHOULD allow the administrator to disable this check. 2072 TEAM implementations MAY support this TLV; and this TLV MUST NOT be 2073 responded to with a NAK TLV. The NAS-Port-Type TLV is defined as 2074 follows: 2076 0 1 2 3 2077 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 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 |M|R| TLV Type | Length | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | Value | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 M 2086 0 (Optional) 2088 R 2090 0 2092 TLV Type 2094 12 for NAS-Port-Type 2096 Length 2098 4 2100 String 2102 The String field is four octets. Values are the same as for the 2103 NAS-Port-Type attribute defined in [RFC2865]. 2105 6.14. Server-Identifier TLV 2107 This TLV allows a EAP server to send a hint to the EAP peer to help 2108 the EAP peer select the appropriate sessionID for session resumption. 2109 The field is a string sent by the EAP server, and the field should be 2110 treated as a opaque string by the peer. During a full-tls-handshake, 2111 the EAP peer MAY keep track of this field and the corresponding 2112 sessionID, and use it as a hint to select the appropriate sessionID 2113 during session resumption. 2115 TEAM implementations MAY support this TLV and this TLV MUST NOT be 2116 responded to with a NAK TLV. The Server-Identifier TLV is defined as 2117 follows: 2119 0 1 2 3 2120 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 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 |M|R| TLV Type | Length | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | String... 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 M 2129 0 (Optional) 2131 R 2133 0 2135 TLV Type 2137 13 for Server-Identifier 2139 Length 2141 >= 0 2143 String 2145 Contains an identifier sent by the EAP server. 2147 6.15. Identity-Type TLV 2149 The Identity-Type TLV allows an EAP server to send a hint to help the 2150 EAP-peer select the right type of identity; for example; user or 2151 machine. 2153 TEAM implementations MAY support this TLV, which cannot be responded 2154 to with a NAK TLV. 2156 If the Identity Type field does not contain one of the known values 2157 or if the EAP peer does not have an identity corresponding to the 2158 identity-type, then the peer MUST ignore the value. The Identity- 2159 Type TLV is defined as follows: 2161 0 1 2 3 2162 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 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 |M|R| TLV Type | Length | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Identity Type | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 M 2171 0 (Optional) 2173 R 2175 0 2177 TLV Type 2179 14 for Identity-Type 2181 Length 2183 2 2185 Identity Type 2187 The Identity Type field is two octets. Values include: 2188 1 - Human 2189 2 - Machine 2191 6.16. Server-Trusted-Root TLV 2193 The Server-Trusted-Root TLV allows the peer to send a request to the 2194 EAP server for a trusted root in PKCS #7 format. 2196 The Server-Trusted-Root TLV is always marked as optional, and cannot 2197 be responded to with a NAK TLV. TEAM server implementations that 2198 claim to support provisioning MUST support Server-Trusted-Root TLV, 2199 PKCS#7 TLV, and the PKCS#7-Server-Certificate-Root credential format 2200 defined in this TLV. TEAM peer implementations may not support this 2201 TLV. 2203 The Server-Trusted-Root TLV can only be sent as an inner TLV (inside 2204 the TEAM Phase 2 conversation), in both server unauthenticated tunnel 2205 provisioning mode, and the regular authentication process. 2207 The peer MUST NOT request, or accept the trusted root sent inside the 2208 Server-Root credential TLV by the EAP server until it has completed 2209 authentication of the EAP server, and validated the Crypto-Binding 2210 TLV. The peer may receive a trusted root, but is not required to use 2211 the trusted root received from the EAP server. 2213 If the EAP server sets credential-format to PKCS#7-Server- 2214 Certificate-Root, then the Server-Trusted-Root TLV MUST contain the 2215 root of the certificate chain of the certificate issued to the EAP 2216 server packages in a PKCS#7 TLV. If the Server certificate is a 2217 self-signed certificate, then the root is the self-signed 2218 certificate. In this case, the EAP server does not have to sign the 2219 certificate inside the PCKS#7 TLV since it does not necessarily have 2220 access to the private key for it. 2222 If the Server-Trusted-Root TLV credential format does not contain one 2223 of the known values, then the EAP server MUST ignore the value. 2225 The Server-Trusted-Root TLV is defined as follows: 2227 0 1 2 3 2228 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 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 |M|R| TLV Type | Length | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Credential Type | TLVs... 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2235 M 2237 0 (Optional) 2239 R 2241 0 2243 TLV Type 2245 15 for Server-Trusted-Root 2247 Length 2249 >= 2 2251 Credential Type 2253 The Credential Type field is two octets. Values include: 2254 1 - PKCS#7-Server-Certificate-Root 2256 TLVs 2258 This (optional) field contains a list of TLVs associated with the 2259 Server-Trusted-Root TLV. The TLVs utilize the same format 2260 described Section 6.1 and MUST NOT have the mandatory bit set. 2261 See Section 6.19.5 for further information. 2263 6.17. PKCS#7 TLV 2265 This TLV contains a certificate or certificate chain requested by the 2266 peer in PKCS#7 format [RFC2315]. 2268 The PKCS#7 TLV is always marked as optional, and cannot be responded 2269 to with a NAK TLV. TEAM server implementations that claim to support 2270 provisioning MUST support this TLV. TEAM peer implementations may 2271 not support this TLV. 2273 If the PKCS#7 TLV contains a certificate or certificate chain that is 2274 not acceptable to the peer, then peer MUST ignore the value. 2276 The PKCS#7 TLV is defined as follows: 2278 0 1 2 3 2279 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 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 |M|R| TLV Type | Length | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | PKCS#7 data... 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 M 2288 0 (Optional) 2290 R 2292 0 2294 TLV Type 2296 17 for PKCS#7 2298 Length 2300 >= 0 2302 PKCS#7 Data 2304 This field contains a certificate or certificate chain in PKCS#7 2305 format. 2307 6.18. Request-Action-TLV 2309 The Request-Action TLV MAY be sent by the peer along with 2310 acknowledged failure. It allows the peer to request the EAP server 2311 to negotiate EAP methods or process TLVs specified in the failure 2312 packet. The server MAY ignore this TLV. 2314 TEAM implementations MUST support this TLV, which cannot be responded 2315 to with a NAK TLV. 2317 The Request-Action TLV is defined as follows: 2319 0 1 2 3 2320 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 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 |M|R| TLV Type | Length | 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 | Action | 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 M 2329 1 (Mandatory) 2331 R 2333 0 2335 TLV Type 2337 16 for Request-Action 2339 Length 2341 2 2343 Action 2345 The Action field is two octets. Values include: 2347 0 - Reserved 2348 1 - Process-TLV 2349 2 - Negotiate-EAP 2351 6.19. TLV Rules 2353 To save round trips, multiple TLVs can be sent in the single TEAM 2354 packet. However, the encapsulation of multiple EAP Payload TLVs 2355 within a single TEAM packet is not supported in this version and MUST 2356 NOT be sent. If the peer or EAP server receives multiple EAP Payload 2357 TLVs, then it MUST drop the connection. 2359 The following table defines the meaning of the table entries in the 2360 sections below: 2362 0 This TLV MUST NOT be present in the packet 2363 0+ Zero or more instances of this TLV MAY be present in packet 2364 0-1 Zero or one instances of this TLV MAY be present in packet 2365 1 Exactly one instance of this TLV MUST be present in packet 2367 6.19.1. Outer TLVs 2369 The following table provides a guide to which TLVs may be included in 2370 the TEAM packet outside the TLS channel, which kind of packets, and 2371 in what quantity: 2373 +---------+----------+---------+---------+--------------------------+ 2374 | Request | Response | Success | Failure | TLV in unencrypted-TLVs | 2375 | | | | | field | 2376 +---------+----------+---------+---------+--------------------------+ 2377 | 0-1 | 0 | 0 | 0 | Server-Identifier TLV | 2378 | 0+ | 0+ | 0 | 0 | Vendor-Specific TLV | 2379 +---------+----------+---------+---------+--------------------------+ 2381 Outer-TLVs MUST be marked as optional. Vendor-TLVs inside a Vendor- 2382 Specific TLV MUST be marked as optional when included in Outer TLVs. 2383 Outer-TLVs MUST NOT be included in messages after the first two TEAM 2384 messages sent by peer and EAP server respectively, i.e., the first 2385 EAP server to peer message and first peer to EAP server message. If 2386 a message is fragmented, the whole set of fragments is counted as one 2387 message. If Outer-TLVs are included in messages after the first two 2388 TEAM messages, they MUST be ignored. 2390 6.19.2. Inner TLVs 2392 The following table provides a guide to which Inner TLVs may be 2393 encapsulated in TLS in TEAM Phase 2, in which kind of packets, and in 2394 what quantity: 2396 +---------+----------+---------+---------+---------------------+ 2397 | Request | Response | Success | Failure | Inner TLV | 2398 +---------+----------+---------+---------+---------------------+ 2399 | 0-1 | 0-1 | 0-1 | 0-1 | Intermediate-Result | 2400 | 0-1 | 0-1 | 0 | 0 | EAP-Payload | 2401 | 0-1 | 0-1 | 1 | 1 | Result | 2402 | 0-1 | 0-1 | 1 | 1 | Crypto-Binding | 2403 | 0+ | 0+ | 0+ | 0+ | Error | 2404 | 0+ | 0+ | 0 | 0 | NAK | 2405 | 0-1 | 0-1 | 0-1 | 0-1 | Connection-Binding | 2406 | 0+ | 0+ | 0+ | 0+ | Vendor-Specific | 2407 | 0+ | 0 | 0+ | 0-1 | URI | 2408 | 0+ | 0 | 0 | 0 | Identity-Type | 2409 | 0+ | 0+ | 0+ | 0+ | Server-Trusted-Root | 2410 | 0 | 0-1 | 0 | 0-1 | Request-Action | 2411 +---------+----------+---------+---------+---------------------+ 2413 Vendor TLVs (included in Vendor-Specific TLVs) sent in the protected 2414 success and failure packets MUST be marked as optional. If Vendor 2415 TLVs sent in protected success/failure packets are marked as 2416 Mandatory, then the peer or EAP server MUST drop the connection. 2418 +----------+--------------------------------------------------------+ 2419 | Packet | Description | 2420 | Type | | 2421 +----------+--------------------------------------------------------+ 2422 | Request | TLS packet sent by the EAP server to the peer | 2423 | Response | TLS packet sent by the peer to the EAP server | 2424 | Success | TLS packet sent by the peer or EAP server as a | 2425 | | protected success indication | 2426 | Failure | TLS packet sent by the peer or EAP server as a | 2427 | | protected failure indication | 2428 +----------+--------------------------------------------------------+ 2430 6.19.3. EAP-Payload TLV 2432 The EAP-Payload TLV can contain other TLVs. The table below defines 2433 which TLVs can be contained inside the EAP-Payload TLV and how many 2434 such TLVs can be included. 2436 +---------+----------+-----------------+ 2437 | Request | Response | TLV | 2438 +---------+----------+-----------------+ 2439 | 0+ | 0+ | Vendor-Specific | 2440 | 0+ | 0+ | Identity-Type | 2441 +---------+----------+-----------------+ 2443 Vendor TLVs encapsulated in a Vendor-Specific TLV MUST be marked as 2444 optional when included in an EAP-Payload TLV. 2446 6.19.4. Connection-Binding TLV 2448 The Connection-Binding TLV can contain other TLVs. The table below 2449 defines which TLVs can be contained inside the Connection-Binding TLV 2450 and how many such TLVs can be included. 2452 +---------+----------+--------------------+ 2453 | Request | Response | TLV | 2454 +---------+----------+--------------------+ 2455 | 0-1 | 0 | Calling-Station-ID | 2456 | 0-1 | 0 | Called-Station-ID | 2457 | 0-1 | 0 | NAS-Port-Type | 2458 | 0+ | 0+ | Vendor-Specific | 2459 +---------+----------+--------------------+ 2461 Vendor TLVs encapsulated in a Vendor-Specific TLV MUST be marked as 2462 optional when included in a Connection-Binding TLV. 2464 6.19.5. Server-Trusted-Root TLV 2466 The Server-Trusted-Root TLV can contain other TLVs. The table below 2467 defines which TLVs can be contained inside the Server-Trusted-Root 2468 TLV and how many such TLVs can be included. 2470 +---------+----------+--------+ 2471 | Request | Response | TLV | 2472 +---------+----------+--------+ 2473 | 0-1 | 0 | PKCS#7 | 2474 +---------+----------+--------+ 2476 7. Security Considerations 2478 7.1. Authentication and Integrity Protection 2480 TEAM provides a server authenticated, encrypted and integrity 2481 protected tunnel. All data within the tunnel has these properties. 2482 Data outside the tunnel such as EAP Success and Failure, Outer-TLVs, 2483 authentication methods negotiated outside of TEAM and the TEAM 2484 headers themselves (including the EAP-Type in the header) are not 2485 protected by this tunnel. 2487 In addition, the Crypto-Binding TLV can reveal a man-in-the-middle 2488 attack described in Section 7.8, below. Hence, the server should not 2489 reveal any sensitive data to the client until after the Crypto- 2490 Binding TLV has been properly verified. 2492 In order to detect the modification of Outer TLVs, the first two 2493 Outer TLV messages sent by both peer and EAP server are included in 2494 the calculation of the Crypto-Binding TLV. Outer-TLVs SHOULD NOT be 2495 included in other TEAM packets since there is no mechanism to detect 2496 modification. 2498 In order to detect modification of EAP-Type sent in the clear (EAP- 2499 Type should be set to TEAM), the EAP-Type sent in the first two 2500 messages by both peer and EAP server is included in the calculation 2501 of Crypto-Binding TLV. The EAP-Type in the clear could be modified 2502 in other TEAM packets and will likely result in failure, hence it is 2503 not included in the Crypto-Binding calculation. 2505 7.2. Method Negotiation 2507 If the peer does not support TEAM, or does not wish to utilize TEAM 2508 authentication, it MUST respond to the initial EAP- Request/ 2509 TEAM-Start with a NAK, suggesting an alternate authentication method. 2510 Since the NAK is sent in cleartext with no integrity protection or 2511 authentication, it is subject to spoofing. Inauthentic NAK packets 2512 can be used to trick the peer and authenticator into "negotiating 2513 down" to a weaker form of authentication, such as EAP- MD5 (which 2514 only provides one way authentication and does not derive a key). 2516 Since a subsequent protected EAP conversation can take place within 2517 the TLS session, selection of TEAM as an authentication method does 2518 not limit the potential secondary authentication methods. As a 2519 result, the only legitimate reason for a peer to NAK TEAM as an 2520 authentication method is that it does not support it. Where the 2521 additional security of TEAM is required, server implementations 2522 SHOULD respond to a NAK with an EAP-Failure, terminating the 2523 authentication conversation. 2525 Since method negotiation outside of TEAM is not protected, if the 2526 peer is configured to allow TEAM and other EAP methods at the same 2527 time, the negotiation is subject to downgrade attacks. Since method 2528 negotiation outside of TEAM is not protected, if the peer is 2529 configured to allow TEAM and previous TEAM versions at the same time, 2530 the negotiation is subject to negotiation downgrade attacks. 2531 However, peers configured to allow TEAM and later TEAM versions may 2532 not be subject to downgrade negotiation attack since the highest 2533 version supported by both peers is checked within the protected 2534 tunnel. 2536 If peer implementations select incorrect methods or credentials with 2537 EAP servers, then attacks are possible on the credentials. Hence, a 2538 TEAM peer implementation should preferably be configured with a set 2539 of credentials and methods that may be used with a specific TEAM 2540 server. The peer implementation may be configured to use different 2541 methods and/or credentials based on the TEAM server. 2543 7.3. TLS Session Cache Handling 2545 In cases where a TLS session has been successfully resumed, in some 2546 circumstances, it is possible for the EAP server to skip TEAM Phase 2547 2, and successfully conclude the conversation with a protected 2548 termination. 2550 TEAM "fast reconnect" is desirable in applications such as wireless 2551 roaming, since it minimizes interruptions in connectivity. It is 2552 also desirable when the "inner" EAP mechanism used is such that it 2553 requires user interaction. The user should not be required to re- 2554 authenticate herself, using biometrics, token cards or similar, every 2555 time the radio connectivity is handed over between access points in 2556 wireless environments. 2558 However, there are issues that need to be understood in order to 2559 avoid introducing security vulnerabilities. 2561 Since Phase 1 of TEAM may not provide client authentication, 2562 establishment of a TLS session (and an entry in the TLS session 2563 cache) does not by itself provide an indication of the peer's 2564 authenticity. 2566 Some TEAM implementations may not be capable of removing TLS session 2567 cache entries established in TEAM Phase 1 after an unsuccessful Phase 2568 2 authentication. In such implementations, the existence of a TLS 2569 session cache entry provides no indication that the peer has 2570 previously been authenticated. As a result, implementations that do 2571 not remove TLS session cache entries after a TEAM Phase 2 2572 authentication or failed protected termination MUST use other means 2573 than successful TLS resumption as the indicator of whether the client 2574 is authenticated or not. The implementation MUST determine that the 2575 client is authenticated only after the completion of protected 2576 termination. Failing to do this would enable a peer to gain access 2577 by completing TEAM Phase 1, tearing down the connection, re- 2578 connecting and resuming TEAM Phase 2, thereby proving herself 2579 authenticated. Thus, TLS resumption MUST only be enabled if the 2580 implementation supports TLS session cache removal. If an EAP server 2581 implementing TEAM removes TLS session cache entries of peers failing 2582 TEAM Phase 2 authentication, then it MAY skip the TEAM Phase 2 2583 conversation entirely after a successful session resumption, 2584 successfully terminating the TEAM conversation as described in 2585 Section 4.4.2. 2587 7.4. Certificate Revocation 2589 Since the EAP server usually has network connectivity during the EAP 2590 conversation, the server is capable of following a certificate chain 2591 or verifying whether the peer's certificate has been revoked. In 2592 contrast, the peer may or may not have network connectivity, and thus 2593 while it can validate the EAP server's certificate based on a pre- 2594 configured set of CAs, it may not be able to follow a certificate 2595 chain or verify whether the EAP server's certificate has been 2596 revoked. 2598 In the case where the peer is initiating a voluntary Layer 2 channel 2599 using PPTP [RFC2637] or L2TP [RFC3931], the peer will typically 2600 already have network connectivity established at the time of channel 2601 initiation. As a result, during the EAP conversation it is capable 2602 of checking for certificate revocation. 2604 As part of the TLS negotiation, the server presents a certificate to 2605 the peer. The peer SHOULD verify the validity of the EAP server 2606 certificate, and SHOULD also examine the EAP server name presented in 2607 the certificate, in order to determine whether the EAP server can be 2608 trusted. Please note that in the case where the EAP authentication 2609 is remoted, the EAP server will not reside on the same machine as the 2610 authenticator, and therefore the name in the EAP server's certificate 2611 cannot be expected to match that of the intended destination. In 2612 this case, a more appropriate test might be whether the EAP server's 2613 certificate is signed by a CA controlling the intended destination 2614 and whether the EAP server exists within a target sub-domain. 2616 In the case where the peer is attempting to obtain network access, it 2617 will not have network connectivity. The TLS Extensions [RFC5246] 2618 support piggybacking of an Online Certificate Status Protocol 2619 [RFC2560] or a Server-based Certificate Validation Protocol [RFC5055] 2620 response within TLS, therefore can be utilized by the peer in order 2621 to verify the validity of server certificate. However, since not all 2622 TLS implementations implement the TLS extensions, it may be necessary 2623 for the peer to wait to check for certificate revocation until after 2624 network access has been obtained. In this case, the peer SHOULD 2625 conduct the certificate status check immediately upon going online 2626 and SHOULD NOT send data until it has received a positive response to 2627 the status request. If the server certificate is found to be invalid 2628 as per client policy, then the peer SHOULD disconnect. 2630 If the client has a policy to require checking certificate revocation 2631 and it cannot obtain revocation information then it may need to 2632 disallow the use of all or some of the inner methods since some 2633 methods may reveal some sensitive information. 2635 7.5. Separation of EAP Server and Authenticator 2637 As a result of a complete TEAM conversation, the EAP endpoints will 2638 mutually authenticate, and derive a session key for subsequent use in 2639 link layer security. Since the peer and EAP client reside on the 2640 same machine, it is necessary for the EAP client module to pass the 2641 session key to the link layer encryption module. 2643 The situation may be more complex on the Authenticator, which may or 2644 may not reside on the same machine as the EAP server. In the case 2645 where the EAP server and the Authenticator reside on different 2646 machines, there are several implications for security. Firstly, the 2647 mutual authentication defined in TEAM will occur between the peer and 2648 the EAP server, not between the peer and the authenticator. This 2649 means that as a result of the TEAM conversation, it is not possible 2650 for the peer to validate the identity of the NAS or channel server 2651 that it is speaking to. 2653 The second issue is that the session key negotiated between the peer 2654 and EAP server will need to be transmitted to the authenticator. 2655 Therefore a secure mechanism needs to be provided to transmit the 2656 session key from the EAP server to the authenticator or channel 2657 server that needs to use the key. The specification of this transit 2658 mechanism is outside the scope of this document. 2660 7.6. Separation of TEAM Phase 1 and 2 Servers 2662 The EAP server involved in TEAM Phase 2 need not necessarily be the 2663 same as the EAP server involved in Phase 1. For example, a local 2664 authentication server or proxy might serve as the endpoint for the 2665 Phase 1 conversation, establishing the TLS channel. Subsequently, 2666 once the EAP-Response/Identity has been received within the TLS 2667 channel, it can be decrypted and forwarded in cleartext to the 2668 destination realm EAP server. The rest of the conversation will 2669 therefore occur between the destination realm EAP server and the 2670 peer, with the local authentication server or proxy acting as an 2671 encrypting/decrypting gateway. This permits a non-TLS capable EAP 2672 server to participate in the TEAM conversation. 2674 Note however that such an approach introduces security 2675 vulnerabilities. Since the EAP Response/Identity is sent in the 2676 clear between the proxy and the EAP server, this enables an attacker 2677 to snoop the user's identity. It also enables a remote environments, 2678 which may be public hot spots or Internet coffee shops, to gain 2679 knowledge of the identity of their users. Since one of the potential 2680 benefits of TEAM is identity protection, this is undesirable. 2682 If the EAP method negotiated during TEAM Phase 2 does not support 2683 mutual authentication, then if the Phase 2 conversation is proxied to 2684 another destination, the TEAM peer will not have the opportunity to 2685 verify the secondary EAP server's identity. Only the initial EAP 2686 server's identity will have been verified as part of TLS session 2687 establishment. 2689 Similarly, if the EAP method negotiated during TEAM Phase 2 is 2690 vulnerable to dictionary attack, then an attacker capturing the 2691 cleartext exchange will be able to mount an offline dictionary attack 2692 on the password. 2694 Finally, when a Phase 2 conversation is terminated at a different 2695 location than the Phase 1 conversation, the Phase 2 destination is 2696 unaware that the EAP client has negotiated TEAM. As a result, it is 2697 unable to enforce policies requiring TEAM. Since some EAP methods 2698 require TEAM in order to generate keys or lessen security 2699 vulnerabilities, where such methods are in use, such a configuration 2700 may be unacceptable. 2702 In summary, TEAM encrypting/decrypting gateway configurations are 2703 vulnerable to attack and SHOULD NOT be used. Instead, the entire 2704 TEAM connection SHOULD be proxied to the final destination, and the 2705 subsequently derived master session keys need to be transmitted back. 2706 This provides end-to-end protection of TEAM. The specification of 2707 this transit mechanism is outside the scope of this document, but 2708 mechanisms similar to those described in [RFC2548] can be used. 2709 These steps protect the client from revealing her identity to the 2710 remote environment. 2712 In order to find the proper TEAM destination, the EAP client SHOULD 2713 place a Network Access Identifier (NAI) [RFC4282] in the Identity 2714 Response. 2716 There may be cases where a natural trust relationship exists between 2717 the (foreign) authentication server and final EAP server, such as on 2718 a campus or between two offices within the same company, where there 2719 is no danger in revealing the identity of the station to the 2720 authentication server. In these cases, a proxy solution without end 2721 to end protection of TEAM MAY be used. If RADIUS [RFC2865] is used 2722 to communicate between gateway and EAP server, then the TEAM 2723 encrypting/decrypting gateway SHOULD provide support for IPsec 2724 protection of RADIUS in order to provide confidentiality for the 2725 portion of the conversation between the gateway and the EAP server, 2726 as described in [RFC3579]. 2728 7.7. Identity Verification 2730 Since the TLS session has not yet been negotiated, the initial 2731 Identity request/response occurs in the clear without integrity 2732 protection or authentication. It is therefore subject to snooping 2733 and packet modification. 2735 In configurations where all users are required to authenticate with 2736 TEAM and the first portion of the TEAM conversation is terminated at 2737 a local backend authentication server, without routing by proxies, 2738 the initial cleartext Identity Request/Response exchange is not 2739 needed in order to determine the required authentication method(s) or 2740 route the authentication conversation to its destination. As a 2741 result, the initial Identity and Request/Response exchange may not be 2742 present, and a subsequent Identity Request/Response exchange MAY 2743 occur after the TLS session is established. 2745 If the initial cleartext Identity Request/Response has been tampered 2746 with, after the TLS session is established, it is conceivable that 2747 the EAP Server will discover that it cannot verify the peer's claim 2748 of identity. For example, the peer's userID may not be valid or may 2749 not be within a realm handled by the EAP server. Rather than 2750 attempting to proxy the authentication to the server within the 2751 correct realm, the EAP server SHOULD terminate the conversation. 2753 The TEAM peer can present the server with multiple identities. This 2754 includes the claim of identity within the initial EAP- Response/ 2755 Identity (MyID) packet, which is typically used to route the EAP 2756 conversation to the appropriate home backend authentication server. 2757 There may also be subsequent EAP-Response/Identity packets sent by 2758 the peer once the TLS channel has been established. 2760 Note that since the TEAM peer may not present a certificate, it is 2761 not always possible to check the initial EAP-Response/Identity 2762 against the identity presented in the certificate, as is done in 2763 [RFC5216]. 2765 Moreover, it cannot be assumed that the peer identities presented 2766 within multiple EAP-Response/Identity packets will be the same. For 2767 example, the initial EAP-Response/Identity might correspond to a 2768 machine identity, while subsequent identities might be those of the 2769 user. Thus, TEAM implementations SHOULD NOT abort the authentication 2770 just because the identities do not match. However, since the initial 2771 EAP-Response/Identity will determine the EAP server handling the 2772 authentication, if this or any other identity is inappropriate for 2773 use with the destination EAP server, there is no alternative but to 2774 terminate the TEAM conversation. 2776 The protected identity or identities presented by the peer within 2777 TEAM Phase 2 may not be identical to the cleartext identity presented 2778 in TEAM Phase 1, for legitimate reasons. In order to shield the 2779 userID from snooping, the cleartext Identity may only provide enough 2780 information to enable routing of the authentication request to the 2781 correct realm. For example, the peer may initially claim the 2782 identity of "nouser@bigco.com" in order to route the authentication 2783 request to the bigco.com EAP server. Subsequently, once the TLS 2784 session has been negotiated, in TEAM Phase 2, the peer may claim the 2785 identity of "fred@bigco.com". Thus, TEAM can provide protection for 2786 the user's identity, though not necessarily the destination realm, 2787 unless the TEAM Phase 1 conversation terminates at the local 2788 authentication server. 2790 As a result, TEAM implementations SHOULD NOT attempt to compare the 2791 Identities claimed with Phases 1 and 2 of the TEAM conversation. 2792 Similarly, if multiple Identities are claimed within TEAM Phase 2, 2793 these SHOULD NOT be compared. An EAP conversation may involve more 2794 than one EAP authentication method, and the identities claimed for 2795 each of these authentications could be different (e.g. a machine 2796 authentication, followed by a user authentication). 2798 7.8. Man-in-the-Middle Attack Protection 2800 TLS protection can address a number of weaknesses in the EAP method; 2801 as well as EAP protocol weaknesses listed in the abstract and 2802 introduction sections in this document. 2804 Hence, the recommended solution is to always deploy authentication 2805 methods with protection of TEAM. 2807 If a deployment chooses to allow a EAP method protected by TEAM 2808 without protection of TEAM or IPsec at the same time, then this opens 2809 up a possibility of a man-in-the-middle attack. 2811 A man-in-the-middle can spoof the client to authenticate to it 2812 instead of the real EAP server; and forward the authentication to the 2813 real server over a protected tunnel. Since the attacker has access 2814 to the keys derived from the tunnel, it can gain access to the 2815 network. 2817 TEAM prevents this attack by using the keys generated by the inner 2818 EAP method in the crypto-binding exchange described in protected 2819 termination section. This attack is not prevented if the inner EAP 2820 method does not generate keys or if the keys generated by the inner 2821 EAP method can be compromised. Hence, in cases where the inner EAP 2822 method does not generate keys, the recommended solution is to always 2823 deploy authentication methods protected by TEAM. 2825 Alternatively, the attack can also be thwarted if the inner EAP 2826 method can signal to the peer that the packets are being sent within 2827 the tunnel. In most cases this may require modification to the inner 2828 EAP method. In order to allow for these implementations, TEAM 2829 implementations should inform inner EAP methods that the EAP method 2830 is being protected by a TEAM tunnel. 2832 Since all sequence negotiations and exchanges are protected by TLS 2833 channel, they are immune to snooping and MITM attacks with the use of 2834 Crypto-Binding TLV. To make sure the same parties are involved 2835 tunnel establishment and previous inner method, before engaging the 2836 next method to sent more sensitive information, both peer and server 2837 MUST use the Crypto-Binding TLV between methods to check the tunnel 2838 integrity. If the Crypto-Binding TLV failed validation, they SHOULD 2839 stop the sequence and terminate the tunnel connection, to prevent 2840 more sensitive information being sent in subsequent methods. 2842 7.9. Cleartext Forgeries 2844 As described in [RFC3748], EAP Success and Failure packets are not 2845 authenticated, so that they may be forged by an attacker without fear 2846 of detection. Forged EAP Failure packets can be used to convince an 2847 EAP peer to disconnect. Forged EAP Success and Failure packets may 2848 be used to convince a peer to disconnect; or convince a peer to 2849 access the network even before authentication is complete, resulting 2850 in denial of service for the peer. 2852 By supporting encrypted, authenticated and integrity protected 2853 success/failure indications, TEAM provides protection against these 2854 attacks. 2856 Once the peer responds with the first TEAM packet; and the EAP server 2857 receives the first TEAM packet from the peer, both MUST silently 2858 discard all clear text EAP messages unless both the TEAM peer and 2859 server have indicated success or failure or error using a protected 2860 error or protected termination mechanism. The success/failure 2861 decisions sent by a protected mechanism indicate the final decision 2862 of the EAP authentication conversation. After success/failure has 2863 been indicated by a protected mechanism, the TEAM client can process 2864 unprotected EAP success and EAP failure message; however MUST ignore 2865 any unprotected EAP success or failure messages where the decision 2866 does not match the decision of the protected mechanism. 2868 After a Fatal alert is received or after protected termination is 2869 complete, the peer or EAP server should accept clear text EAP 2870 messages. If the TEAM tunnel is nested inside another tunnel, then 2871 the clear text EAP messages should only be accepted after protected 2872 termination of outer tunnels. 2874 RFC 3748 states that an EAP Success or EAP Failure packet terminates 2875 the EAP conversation, so that no response is possible. Since EAP 2876 Success and EAP Failure packets are not retransmitted, if the final 2877 packet is lost, then authentication will fail. As a result, where 2878 packet loss is expected to be non-negligible, unacknowledged success/ 2879 failure indications lack robustness. 2881 As a result, a EAP server SHOULD send a clear text EAP Success or 2882 Failure packet after the protected success or failure packet or TLS 2883 alert. The peer MUST NOT require the clear text EAP Success or EAP 2884 Failure if it has received the protected success or failure or TLS 2885 alert. For more details, refer to Section 4.2 of RFC 3748. 2887 7.10. TLS Ciphersuites 2889 Anonymous ciphersuites are vulnerable to man-in-the-middle attacks, 2890 and SHOULD NOT be used with TEAM, unless the EAP methods inside TEAM 2891 can address the man-in-the-middle attack or unless the man-in- the- 2892 middle attack can be addressed by mechanisms external to TEAM. 2894 7.11. Denial of Service Attacks 2896 Denial of service attacks are possible if the attacker can insert or 2897 modify packets in the authentication channel. The attacker can 2898 modify unprotected fields in the TEAM packet such as the EAP protocol 2899 or TEAM version number. This can result in a denial of service 2900 attack. It is also possible for the attacker to modify protected 2901 fields in a packet to cause decode errors resulting in a denial of 2902 service. In these ways the attacker can prevent access for peers 2903 connecting to the network. 2905 Denial of service attacks with multiplier impacts are more 2906 interesting than the ones above. It is possible to multiply the 2907 impact by creating a large number of TLS sessions with the EAP 2908 server. 2910 7.12. Server Unauthenticated Tunnel Provisioning Mode 2912 This section describes the rationale and security risks behind server 2913 unauthenticated tunnel provisioning mode. Server unauthenticated 2914 tunnel provisioning mode can result in potential security 2915 vulnerabilities. Hence, this mode is optional in TEAM 2916 implementations. 2918 In order to achieve strong mutual authentication, it is best to use 2919 an out of band mechanism to pre-provision the device with strong 2920 symmetric or asymmetric keys. In addition, if the device is not 2921 physically secure (mobile or devices at public places), then it is 2922 important to ensure that the device has secure storage. 2924 Server unauthenticated tunnel provisioning mode is not recommended 2925 for use in devices which already support secure provisioning and 2926 secure credential storage capabilities. 2928 If the provisioned credential is a shared key or asymmetric key 2929 issued to the peer, then the credential should only be issued to 2930 devices that can protect the provisioned credentials using secure 2931 storage, or use physical security. 2933 If the credentials are not protected, the attacker can compromise the 2934 provisioned credentials, and use them to get access to the network. 2935 Mobile light weight devices are typically not physically secure. 2936 Another concern is that credentials provisioned to a light weight 2937 mobile device that does not use secure storage could be transferred 2938 to a general operating system and used to get access to the network. 2940 If the provisioned credential is a certificate trusted root of the 2941 EAP server, this is public information and hence not susceptible to 2942 the same attacks as a shared key or asymmetric key. 2944 In server unauthenticated tunnel provisioning mode, an attacker may 2945 terminate the tunnel instead of the real server. The attacker can be 2946 detected after the Crypto-Binding TLV is exchanged and validated. 2947 However, the EAP packets exchanged inside the tunnel until Crypto- 2948 Binding TLV is validated are available in unencrypted form to the 2949 attacker. It is difficult to completely negate the security risk 2950 unless the EAP methods inside the tunnel are secure; or unless 2951 physical wire security is assumed. 2953 The standard credential request/response capability is designed to be 2954 independent of the server unauthenticated tunnel provisioning mode, 2955 and can be used in regular authentication mode to provision other 2956 credentials to the peer that can be used for authentication to the 2957 network, or for potentially authentications to other services. 2959 The security risks vary depending on the type of credential 2960 exchanged, the scope of use of the credential, and the implementation 2961 of the device. 2963 These are a few guidelines to reduce the security risk: 2965 1. Minimize the use of this mode only during initial authentication 2966 to the network to reduce the risk of attack 2968 2. The password-based EAP method used in provisioned mode MUST be 2969 resistant to dictionary attacks 2971 3. Disable this mode by default and require users to initiate 2972 provisioning mode explicitly rather than being prompted during 2973 initiation of regular authentication process 2975 4. Provide appropriate policy capabilities to allow administrators 2976 to lockdown the device and prevent regular users from enabling 2977 the mode 2979 5. Ensure that the EAP methods used support mutual authentication, 2980 key derivation and resistance to dictionary attack 2982 6. Ensure that the keys generated by EAP methods are of sufficient 2983 strength to prevent compounding binding from being compromised 2985 7. Minimize the information disclosed to the EAP server 2987 7.13. Security Claims 2989 Intended use: Wireless or Wired networks, and over the 2990 Internet, where physical security cannot be 2991 assumed 2993 Authentication mechanism: Uses arbitrary EAP and TLS authentication 2994 mechanisms for authentication of the client 2995 and server. 2997 Ciphersuite negotiation: Yes 2999 Mutual authentication: Yes (depends on the type of EAP method used 3000 within the tunnel and the type of 3001 authentication used within TLS) 3003 Integrity protection: Yes 3005 Replay protection: Yes 3007 Confidentiality: Yes 3009 Key derivation: Yes 3011 Key strength: Variable 3013 Dict. attack protection: Yes 3015 Fast reconnect: Yes 3017 Cryptographic binding: Yes 3019 Acknowledged S/F: Yes 3021 Session independence: Yes 3023 Fragmentation: Yes 3025 State synchronization: Yes 3027 The TEAM protocol is unconditionally compliant with the requirements 3028 for WLAN authentication mechanisms, as specified in [RFC4017]. 3030 TEAM derives keys by combining keys from TLS and the inner EAP 3031 methods. It should be noted that the use of TLS ciphersuites with a 3032 particular key lengths does not guarantee that the key strength of 3033 the keys will be equivalent to the length. The key exchange 3034 mechanisms (e.g., RSA or Diffie-Hellman) used must provide sufficient 3035 security or they will be the weakest link. For example, RSA key 3036 sizes with a modulus of 1024 bits provides less than 128 bits of 3037 security; this may provide sufficient key strength for some 3038 applications and not for others. See BCP 86 [RFC3766] for a detailed 3039 analysis of the strength requirements on the public keys used to 3040 exchange symmetric keys. 3042 8. IANA Considerations 3044 This memo specifies new values and registries to be created and 3045 managed by IANA. The policies used to allocate numbers are described 3046 in [RFC5226]. 3048 8.1. EAP Type 3050 This memo requires IANA to allocate a new EAP method type for TEAM. 3051 The placeholder indicated by in section Section 5.2 above shall 3052 be replaced by the new EAP method type upon assignment by IANA. 3054 8.2. TLV Types 3056 IANA is requested to create a registry for TEAM TLV Types. 3058 TLV Types may assume a value between 0 and 16383 of which 0-20 are 3059 allocated in this document Section 6. Additional TLV type codes may 3060 be allocated following the "Specification Required" policy [RFC5226]. 3062 8.3. TLV Values 3064 IANA is requested to create a registry for TEAM TLV Values, populated 3065 initially with entries for the Identity-Type, Credential Type and 3066 Action fields. 3068 The Identity-Type field may assume a value between 0 and 65535, of 3069 which 0-2 are allocated in this document Section 6.15, Additional 3070 Identity-Type values may be allocated following the "Specification 3071 Required" policy [RFC5226]. 3073 The Credential Type field of the Server-Trusted-Root TLV Section 6.16 3074 may assume a value between 0 and 65535, of which 1 is allocated in 3075 this document. Additional Credential Type values may be allocated 3076 following the "Specification Required" policy [RFC5226]. 3078 The Action field field of the Request-Action TLV may assume a value 3079 between 0 and 65535, of which 0-2 have already been allocated. 3080 Additional Action values may be allocated following the 3081 "Specification Required" policy [RFC5226]. 3083 9. Contributors 3085 A great deal of the text in the first draft of this note was taken 3086 from a document by Ashwin Palekar, Dan Simon, Glen Zorn, Simon 3087 Josefsson, Hao Zhou and Joe Salowey; the authors gratefully 3088 acknowledge their contribution. 3090 TEAM is a direct descendent of the Protected Extensible 3091 Authentication Protocol (PEAP), which was created by Glen Zorn while 3092 employed by Cisco Systems. 3094 10. Acknowledgements 3096 Hakan Andersson, Jan-Ove Larsson, Magnus Nystrom, Bernard Aboba, 3097 Vivek Kamath, Stephen Bensley, Narendra Gidwani, Ilan Frenkel, Nancy 3098 Cam-Winget, Victor Lortz, Ashwin Palekar, Dan Simon, Glen Zorn, Simon 3099 Josefsson, Hao Zhou, Joe Salowey, Bernard Aboba, Paul Funk and Jose 3100 Puthenkulam all contributed at various stages to the development of 3101 this protocol. 3103 11. References 3105 11.1. Normative References 3107 [I-D.zorn-emu-eap-pwc] Zorn, G., "A Method for Changing 3108 Cleartext Passwords in the Extensible 3109 Authentication Protocol", March 2011. 3111 [RFC2119] Bradner, S., "Key words for use in RFCs 3112 to Indicate Requirement Levels", 3113 BCP 14, RFC 2119, March 1997. 3115 [RFC3454] Hoffman, P. and M. Blanchet, 3116 "Preparation of Internationalized 3117 Strings ("stringprep")", RFC 3454, 3118 December 2002. 3120 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 3121 Carlson, J., and H. Levkowetz, 3122 "Extensible Authentication Protocol 3123 (EAP)", RFC 3748, June 2004. 3125 [RFC3986] Berners-Lee, T., Fielding, R., and L. 3126 Masinter, "Uniform Resource Identifier 3127 (URI): Generic Syntax", STD 66, 3128 RFC 3986, January 2005. 3130 [RFC4013] Zeilenga, K., "SASLprep: Stringprep 3131 Profile for User Names and Passwords", 3132 RFC 4013, February 2005. 3134 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and 3135 P. Eronen, "The Network Access 3136 Identifier", RFC 4282, December 2005. 3138 [RFC5226] Narten, T. and H. Alvestrand, 3139 "Guidelines for Writing an IANA 3140 Considerations Section in RFCs", 3141 BCP 26, RFC 5226, May 2008. 3143 [RFC5246] Dierks, T. and E. Rescorla, "The 3144 Transport Layer Security (TLS) Protocol 3145 Version 1.2", RFC 5246, August 2008. 3147 11.2. Informative References 3149 [I-D.ietf-emu-eaptunnel-req] Hoeper, K., Hanna, S., Zhou, H., and J. 3150 Salowey, "Requirements for a Tunnel 3151 Based EAP Method", 3152 draft-ietf-emu-eaptunnel-req-09 (work 3153 in progress), December 2010. 3155 [IEEE.802-11.2007] IEEE Computer Society, "Information 3156 technology - Telecommunications and 3157 information exchange between systems - 3158 Local and metropolitan area networks - 3159 Specific requirements - Part 11: 3160 Wireless LAN Medium Access Control 3161 (MAC) and Physical Layer (PHY) 3162 specifications", IEEE Standard 802.11, 3163 June 2007. 3165 [IEEE.802-1X.2004] IEEE Computer Society, "IEEE Standard 3166 for Local and metropolitan area 3167 networks: Port-Based Network Access 3168 Control", IEEE Standard 802.1X, 3169 December 2004. 3171 [RFC1968] Meyer, G. and K. Fox, "The PPP 3172 Encryption Control Protocol (ECP)", 3173 RFC 1968, June 1996. 3175 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., 3176 Carr, D., and T. Coradetti, "The PPP 3177 Multilink Protocol (MP)", RFC 1990, 3178 August 1996. 3180 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic 3181 Message Syntax Version 1.5", RFC 2315, 3182 March 1998. 3184 [RFC2548] Zorn, G., "Microsoft Vendor-specific 3185 RADIUS Attributes", RFC 2548, 3186 March 1999. 3188 [RFC2560] Myers, M., Ankney, R., Malpani, A., 3189 Galperin, S., and C. Adams, "X.509 3190 Internet Public Key Infrastructure 3191 Online Certificate Status Protocol - 3192 OCSP", RFC 2560, June 1999. 3194 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., 3195 Taarud, J., Little, W., and G. Zorn, 3196 "Point-to-Point Tunneling Protocol", 3197 RFC 2637, July 1999. 3199 [RFC2865] Rigney, C., Willens, S., Rubens, A., 3200 and W. Simpson, "Remote Authentication 3201 Dial In User Service (RADIUS)", 3202 RFC 2865, June 2000. 3204 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS 3205 (Remote Authentication Dial In User 3206 Service) Support For Extensible 3207 Authentication Protocol (EAP)", 3208 RFC 3579, September 2003. 3210 [RFC3580] Congdon, P., Aboba, B., Smith, A., 3211 Zorn, G., and J. Roese, "IEEE 802.1X 3212 Remote Authentication Dial In User 3213 Service (RADIUS) Usage Guidelines", 3214 RFC 3580, September 2003. 3216 [RFC3766] Orman, H. and P. Hoffman, "Determining 3217 Strengths For Public Keys Used For 3218 Exchanging Symmetric Keys", BCP 86, 3219 RFC 3766, April 2004. 3221 [RFC3931] Lau, J., Townsley, M., and I. Goyret, 3222 "Layer Two Tunneling Protocol - Version 3223 3 (L2TPv3)", RFC 3931, March 2005. 3225 [RFC4017] Stanley, D., Walker, J., and B. Aboba, 3226 "Extensible Authentication Protocol 3227 (EAP) Method Requirements for Wireless 3228 LANs", RFC 4017, March 2005. 3230 [RFC4962] Housley, R. and B. Aboba, "Guidance for 3231 Authentication, Authorization, and 3232 Accounting (AAA) Key Management", 3233 BCP 132, RFC 4962, July 2007. 3235 [RFC5055] Freeman, T., Housley, R., Malpani, A., 3236 Cooper, D., and W. Polk, "Server-Based 3237 Certificate Validation Protocol 3238 (SCVP)", RFC 5055, December 2007. 3240 [RFC5216] Simon, D., Aboba, B., and R. Hurst, 3241 "The EAP-TLS Authentication Protocol", 3242 RFC 5216, March 2008. 3244 [RFC5247] Aboba, B., Simon, D., and P. Eronen, 3245 "Extensible Authentication Protocol 3246 (EAP) Key Management Framework", 3247 RFC 5247, August 2008. 3249 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based 3250 Extract-and-Expand Key Derivation 3251 Function (HKDF)", RFC 5869, May 2010. 3253 [RFC5931] Harkins, D. and G. Zorn, "Extensible 3254 Authentication Protocol (EAP) 3255 Authentication Using Only a Password", 3256 RFC 5931, August 2010. 3258 Appendix A. Compliance with Requirements for a Tunnel Based EAP Method 3260 The following subsections describe the TEAM protocol's compliance 3261 with the requirements given in [I-D.ietf-emu-eaptunnel-req]. 3263 A.1. General Requirements 3265 o TEAM includes a Security Claims section and satisfies all 3266 mandatory requirements listed in section 2.2 of [RFC4017]. 3267 o TEAM meets the MUST and SHOULD requirements of [RFC5247], 3268 including generation of the MSK, ESMK, Peer-Id, Server-Id, and 3269 Session-Id. 3270 o TEAM is not tied to any single cryptographic algorithm. A variety 3271 of ciphersuites can be negotiated in TEAM phase 1 which include a 3272 plethora of cryptographic algorithms. Numerous phase 2 3273 authentication methods are supported which, likewise, constitute a 3274 plethora of cryptographic algorithms. 3275 o TEAM meets all the MUST and SHOULD requirements in section 3 of 3276 [RFC4962] to the extent that they apply to an EAP method (and not 3277 to the use of a key derived from TEAM). In particular TEAM keys 3278 are vine-ripened and very fresh. 3280 A.2. Tunnel Requirements 3282 o TEAM uses TLS version 1.2 in phase 1 and satisfies all of the 3283 mandatory TLS requirements of section 4.2.1 3284 [I-D.ietf-emu-eaptunnel-req]. 3285 o TEAM supports fragmentation and reassembly per section 4.2.2 of 3286 [I-D.ietf-emu-eaptunnel-req]. 3288 o Modification of data outside the tunnel is not protected but any 3289 such modification does not cause an exploitable vulnerability and 3290 can be detected Section 7.1. 3292 A.3. Tunnel Payload Requirements 3294 o TEAM AVPs are extensible. 3295 o TEAM is an EAP method and supports challenge/response operations 3296 that are typical of EAP methods. 3297 o It is possible to indicate whether a TLV is mandatory or not. 3298 o TEAM supports Vendor Specific extensions. 3299 o TEAM supports indication of result after each changed inner 3300 method. 3302 A.4. Channel Binding Requirements 3304 o To the extent that it is appropriate to rely on adherence to a 3305 "work-in-progress", TEAM supports Channel Binding requirements. 3306 Furthermore, as that "work-in-progress" proceeds in its work there 3307 is no reason why TEAM could not continue to meet requirements. 3309 A.5. Username/Password Requirements 3311 o TEAM supports the required use of usernames and passwords in 3312 section 4.5 of [I-D.ietf-emu-eaptunnel-req] through the use of the 3313 EAP/Identity exchange and GTC [RFC3748], and EAP-PWC 3314 [I-D.zorn-emu-eap-pwc]. Note, however, that in order to comply 3315 with the requirements of [I-D.ietf-emu-eaptunnel-req] the user 3316 name contained in the EAP/Identity/Response and the password 3317 contined in the EAP-GTC/Response messages MUST be processed 3318 according to the rules of the [RFC4013] profile of [RFC3454]. 3319 Furthermore, the strings in question SHALL be considered to be 3320 "stored strings" (per [RFC3454]), and unassigned code points are 3321 therefore prohibited. The output SHALL be the binary 3322 representation of the processed UTF-8 character string. 3323 Prohibited output and unassigned codepoints encountered during 3324 SASLprep pre-processing SHALL cause a failure of pre-processing, 3325 and the output MUST NOT be used. 3326 o In addition, TEAM supports the use of username/password 3327 authentication that allows for an EAP peer and EAP server to 3328 authenticate each other based on knowledge of a password without 3329 that password being sent in any format between the peer and 3330 server. 3331 o The TEAM server is authenticated before any possible transmission 3332 of a password and a peer can check whether the certificate of a 3333 TEAM server has been revoked or not using OCSP. 3335 A.6. Requirements Around Carriage of EAP Methods 3337 o TEAM supports carrying inner EAP methods without modification. 3338 These methods are negotiated and can be chained. 3339 o TEAM supports cryptographic binding of keys derived from EAP 3340 methods. 3342 Authors' Addresses 3344 Glen Zorn 3345 Network Zen 3346 227/358 Thanon Sanphawut 3347 Bang Na, Bangkok 10260 3348 Thailand 3350 Phone: +66 (0) 87-040-4617 3351 EMail: gwz@net-zen.net 3353 Qin Wu 3354 Huawei Technologies Co., Ltd. 3355 101 Software Avenue, Yuhua District 3356 Nanjing, Jiangsu 21001 3357 China 3359 Phone: +86-25-84565892 3360 EMail: sunseawq@huawei.com 3362 Dan Harkins 3363 Aruba Networks 3364 1322 Crossman Avenue 3365 Sunnyvale, CA 94089-1113 3366 United States of America 3368 EMail: dharkins@arubanetworks.com