idnits 2.17.1 draft-ietf-emu-eaptunnel-req-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '... MUST - indicates an absolute req...' RFC 2119 keyword, line 169: '... MUST NOT - indicates something a...' RFC 2119 keyword, line 171: '... SHOULD - indicates a strong reco...' RFC 2119 keyword, line 173: '... SHOULD NOT - indicates a strong ...' RFC 2119 keyword, line 175: '... MAY - indicates a willingness to...' (95 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 17, 2010) is 4963 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group K. Hoeper 3 Internet-Draft Motorola, Inc. 4 Intended status: Informational S. Hanna 5 Expires: March 21, 2011 Juniper Networks 6 H. Zhou 7 J. Salowey, Ed. 8 Cisco Systems, Inc. 9 September 17, 2010 11 Requirements for a Tunnel Based EAP Method 12 draft-ietf-emu-eaptunnel-req-08.txt 14 Abstract 16 This memo defines the requirements for a tunnel-based Extensible 17 Authentication Protocol (EAP) Method. This method will use Transport 18 Layer Security (TLS) to establish a secure tunnel. The tunnel will 19 provide support for password authentication, EAP authentication and 20 the transport of additional data for other purposes. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 21, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Conventions Used In This Document . . . . . . . . . . . . . . 5 72 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 74 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 75 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 76 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 77 3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7 78 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 79 3.7. Client Authentication During Tunnel Establishment . . . . 8 80 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 81 3.9. Certificate-less Authentication and Generic EAP Method 82 Extension . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9 86 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9 87 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 88 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 89 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 90 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 91 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 11 92 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 93 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11 94 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 95 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 96 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 97 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 98 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 99 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13 100 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 101 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 102 4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13 103 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 104 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 105 4.3.6. Internationalization of Display Strings . . . . . . . 14 106 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 107 4.5. Requirements Associated with Carrying Username and 108 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 109 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 110 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14 111 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 112 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 113 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 114 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 115 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16 116 4.6. Requirements Associated with Carrying EAP Methods . . . . 16 117 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 118 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 119 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16 120 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 121 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 123 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 125 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 126 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18 127 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 128 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 129 6.4. Separation of TLS Tunnel and Inner Authentication 130 Termination . . . . . . . . . . . . . . . . . . . . . . . 20 132 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 133 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 134 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 136 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22 138 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23 140 Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 144 1. Introduction 146 Running EAP methods within a TLS protected tunnel has been deployed 147 in several different solutions. EAP methods supporting this include 148 PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this 149 has worked well so there is consensus to continue to use TLS as the 150 basis for a tunnel method. There have been various reasons for 151 employing a protected tunnel for EAP processes. They include 152 protecting weak authentication exchanges, such as username and 153 password. In addition a protected tunnel can provide means to 154 provide peer identity protection and EAP method chaining. Finally, 155 systems have found it useful to transport additional types of data 156 within the protected tunnel. 158 This document describes the requirements for an EAP tunnel method as 159 well as for a password protocol supporting legacy password 160 verification within the tunnel method. 162 2. Conventions Used In This Document 164 Use of each capitalized word within a sentence or phrase carries the 165 following meaning during the EMU WG's method selection process: 167 MUST - indicates an absolute requirement 169 MUST NOT - indicates something absolutely prohibited 171 SHOULD - indicates a strong recommendation of a desired result 173 SHOULD NOT - indicates a strong recommendation against a result 175 MAY - indicates a willingness to allow an optional outcome 177 Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 178 "MAY" carry their normal meaning and are not subject to these 179 definitions. 181 3. Use Cases 183 To motivate and explain the requirements in this document, a 184 representative set of use cases for the EAP tunnel method are 185 supplied here. The candidate tunnel method needs to support all of 186 the use cases that are marked below as "MUST". 188 3.1. Password Authentication 190 Many legacy systems only support user authentication with passwords. 191 Some of these systems require transport of the actual username and 192 password to the authentication server. This is true for systems 193 where the authentication server does not have access to the cleartext 194 password or a consistent transform of the cleartext password. 195 Example of such systems are one time password (OTP) systems and other 196 systems where the username and password are submitted to an external 197 party for validation. The tunnel method MUST support transporting 198 cleartext username and password to the EAP server. It MUST NOT 199 reveal information about the username and password to parties in the 200 communication path between the peer and the EAP Server. The 201 advantage any attacker gains against the tunneled method when 202 employing a username and password for authentication MUST be through 203 interaction and not computation. The tunnel MUST support protection 204 from man-in-the-middle attacks. The combination of the tunnel 205 authentication and password authentication MUST enable mutual 206 authentication. 208 Since EAP authentication occurs before network access is granted the 209 tunnel method SHOULD enable an inner exchange to provide support for 210 minimal password management tasks including password change, "new PIN 211 mode", and "next token mode" required by some systems. 213 3.2. Protection of Weak EAP Methods 215 Some existing EAP methods have vulnerabilities that could be 216 eliminated or reduced by running them inside a protected tunnel. For 217 example, a EAP-MD5 does not provide mutual authentication or 218 protection from dictionary attacks. Without extra protection, 219 tunnel-based EAP methods are vulnerable to a special type of tunnel 220 man-in-the-middle attack [TUNNEL-MITM]. This attack is referred to 221 as "tunnel MitM attack" in the remainder of this document. The 222 additional protection needed to thwart tunnel MitM attacks depends on 223 the inner method executed within the tunnel. When weak methods are 224 used, these attacks can be mitigated via security policies that 225 require the method to be used only within a tunnel. On the other 226 hand, a technical solution (so-called cryptographic bindings) can be 227 used whenever the inner method derives key material and is not 228 susceptible to attacks outside a tunnel. Only the latter mitigation 229 technique can be made an actual requirement for tunnel-based EAP 230 methods (see Section 4.6.3), while security policies are outside the 231 scope of this requirement draft. Please refer to the NIST 232 Recommendation for EAP Methods Used in Wireless Network Access 233 Authentication [NIST SP 800-120] and [LCN 2010] for a discussion on 234 security policies and complete solutions for thwarting tunnel MitM 235 attacks. 237 The tunnel method MUST support protection of weak EAP methods. 238 Cryptographic protection from tunnel MitM attacks MUST be provided 239 for all key generating methods. In combination with an appropriate 240 security policy this will thwart MitM attacks against inner methods. 242 3.3. Chained EAP Methods 244 Several circumstances are best addressed by using chained EAP 245 methods. For example, it may be desirable to authenticate the user 246 and also authenticate the device being used. However, chained EAP 247 methods from different conversations can be re-directed into the same 248 conversation by an attacker giving the authenticator the impression 249 that both conversations terminate at the same end-point. 250 Cryptographic binding can be used to bind the results of chained key 251 generating methods together or to an encompassing tunnel. 253 The tunnel method MUST support chained EAP methods while including 254 protection against attacks on method chaining. 256 3.4. Identity Protection 258 When performing an EAP authentication, the peer may want to protect 259 its identity and only disclose it to a trusted EAP server. This 260 helps to maintain peer privacy. 262 The tunnel method MUST support identity protection, therefore the 263 identity of the peer used for authentication purposes MUST NOT be 264 obtainable by any entity other than the EAP server terminating the 265 tunnel method. Peer identity protection provided by the tunnel 266 method applies to tunnel method and inner method specific identities. 267 Note that the peer may need to expose the realm portion of the EAP 268 outer identity in the NAI [RFC4282] in a roaming scenario in order to 269 reach the appropriate authentication server. 271 3.5. Anonymous Service Access 273 When network service is provided, it is sometimes desirable for a 274 user to gain network access in order to access limited services for 275 emergency communication or troubleshooting information. To avoid 276 eavesdropping, it's best to negotiate link layer security as with any 277 other authentication. 279 Therefore, the tunnel method SHOULD allow anonymous peers or server- 280 only authentication, while still deriving keys that can be used for 281 link layer security. The tunnel method MAY also allow for the bypass 282 of server authentication processing on the client. 284 Forgoing user or server authentication increases the chance of man- 285 in-the-middle and other types of attacks that can compromise the 286 derived keys used for link layer security. Therefore, passwords and 287 other sensitive information MUST NOT be disclosed to an 288 unauthenticated server, or to a server that is not authorized to 289 authenticate the user. 291 3.6. Network Endpoint Assessment 293 The Network Endpoint Assessment (NEA) protocols and reference model 294 described in [RFC5209] provide a standard way to check the health 295 ("posture") of a device at or after the time it connects to a 296 network. If the device does not comply with the network's 297 requirements, it can be denied access to the network or granted 298 limited access to remediate itself. EAP is a convenient place for 299 conducting an NEA exchange. 301 The tunnel method SHOULD support carrying NEA protocols such as PB- 302 TNC [RFC5793]. Depending on the specifics of the tunnel method, 303 these protocols may be required to be carried in an EAP method. 305 3.7. Client Authentication During Tunnel Establishment 307 In some cases the peer will have credentials that allow it to 308 authenticate during tunnel establishment. These credentials may only 309 partially authenticate the identity of the peer and additional 310 authentication may be required inside the tunnel. For example, a 311 communication device may be authenticated during tunnel 312 establishment, in addition user authentication may be required to 313 satisfy authentication policy. The tunnel method MUST be capable of 314 providing client side authentication during tunnel establishment. 316 3.8. Extensibility 318 The tunnel method MUST provide extensibility so that additional data 319 related to authentication, authorization and network access can be 320 carried inside the tunnel in the future. This removes the need to 321 develop new tunneling methods for specific purposes. 323 An application for extensibility is credential provisioning. When a 324 peer has authenticated with EAP, this is a convenient time to 325 distribute credentials to that peer that may be used for later 326 authentication exchanges. For example, the authentication server can 327 provide a private key or shared key to the peer that can be used by 328 the peer to perform rapid re-authentication or roaming. In addition 329 there have been proposals to perform enrollment within EAP, such as 330 [I-D.mahy-eap-enrollment]. Another use for extensibility is support 331 for alternate authentication frameworks within the tunnel. 333 3.9. Certificate-less Authentication and Generic EAP Method Extension 335 In some cases the peer will not have a way to verify a server 336 certificate and in some cases a server might not have a certificate 337 to verify. Therefore, it is desirable to support certificate-less 338 authentication. An application for this is credential provisioning 339 where the peer and server authenticate each other with a shared 340 password and credentials for subsequent authentication (e.g. a key 341 pair and certificate or a shared key) can be passed inside the 342 tunnel. Another application is to extend existing EAP methods with 343 new features such as channel bindings. 345 Great care must be taken when attempting to perform certificate-less 346 authentication. One way of doing it is to establish the tunnel 347 without full server or client verification and inside the tunnel use 348 an EAP method that performs mutual authentication and key derivation. 349 If this technique is used the inner EAP method MUST provide 350 resistance to dictionary attack and a cryptographic binding between 351 the inner method and the tunnel method MUST be established. In 352 addition the cipher suite used to establish the tunnel MUST derive 353 the master key using contribution from both client and server, as in 354 ephemeral Diffie-Hellman cipher suites. 356 The tunnel method MAY allow for certificate-less authentication. 358 4. Requirements 360 4.1. General Requirements 362 4.1.1. RFC Compliance 364 The tunnel method MUST include a Security Claims section with all 365 security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In 366 addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 367 3748 that tunnel methods MUST support protection against man-in-the- 368 middle attacks. Furthermore, the tunnel method MUST support identity 369 protection as specified in Section 7.3 in RFC 3748. 371 The tunnel method MUST be unconditionally compliant with RFC 4017 372 [RFC4017] (using the definition of "unconditionally compliant" 373 contained in section 1.1 of RFC 4017). This means that the method 374 MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT 375 requirements in RFC 4017. 377 The tunnel method MUST meet all the MUST and SHOULD requirements 378 relevant to EAP methods contained in the EAP Key Management Framework 379 [RFC5247] or any successor. This includes the generation of the MSK, 380 EMSK, Peer-Id, Server-Id and Session-Id. These requirements will 381 enable the tunnel method to properly fit into the EAP key management 382 framework, maintaining all of the security properties and guarantees 383 of that framework. 385 The tunnel method MUST NOT be tied to any single cryptographic 386 algorithm. Instead, it MUST support run-time negotiation to select 387 among an extensible set of cryptographic algorithms, such as 388 algorithms used with certificates presented during tunnel 389 establishment. This "cryptographic algorithm agility" provides 390 several advantages. Most important, when a weakness in an algorithm 391 is discovered or increased processing power overtakes an algorithm, 392 users can easily transition to a new algorithm. Also, users can 393 choose the algorithm that best meets their needs. 395 The tunnel method MUST meet the SHOULD and MUST requirements 396 pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. 397 This includes: cryptographic algorithm independence; strong, fresh 398 session keys; replay detection; keying material confidentiality and 399 integrity; and confirmation of cipher suite selection. 401 4.2. Tunnel Requirements 403 The following section discusses requirements for TLS Tunnel 404 Establishment. 406 4.2.1. TLS Requirements 408 The tunnel based method MUST support TLS version 1.2 [RFC5246] and 409 may support earlier versions to enable the possibility of backwards 410 compatibility. 412 4.2.1.1. Cipher Suites 414 4.2.1.1.1. Cipher Suite Negotiation 416 Cipher suite negotiations always suffer from downgrading attacks when 417 they are not secured by any kind of integrity protection. A common 418 practice is a post integrity check in which, as soon as available, 419 the established keys (here the tunnel key) are used to derive 420 integrity keys. These integrity keys are then used by peer and 421 authentication server to verify whether the cipher suite negotiation 422 has been maliciously altered by another party. 424 Integrity checks prevent downgrading attacks only if the derived 425 integrity keys and the employed integrity algorithms cannot be broken 426 in real-time. See Section 6.1 or [KHLC07] for more information on 427 this. Hence, the tunnel method MUST provide integrity protected 428 cipher suite negotiation with secure integrity algorithms and 429 integrity keys. 431 TLS provides protected cipher suite negotiation as long as all the 432 cipher suites supported provide authentication, key establishment and 433 data integrity protection as discussed in Section 6.1. 435 4.2.1.1.2. Tunnel Data Protection Algorithms 437 In order to prevent attacks on the cryptographic algorithms employed 438 by inner authentication methods, a tunnel protocol's protection needs 439 to provide a basic level of algorithm strength. The tunnel method 440 MUST provide at least one mandatory to implement cipher suite that 441 provides the equivalent security of 128-bit AES for encryption and 442 message authentication. See Part 1 of the NIST Recommendation for 443 Key Management [NIST SP 800-57] for a discussion of the relative 444 strengths of common algorithms. 446 4.2.1.1.3. Tunnel Authentication and Key Establishment 448 A tunnel method MUST provide unidirectional authentication from 449 authentication server to EAP peer and mutual authentication between 450 authentication server and EAP peer. The tunnel method MUST provide 451 at least one mandatory to implement cipher suite that provides 452 certificate-based authentication of the server and provides optional 453 certificate-based authentication of the client. Other types of 454 authentication MAY be supported. 456 At least one mandatory to implement cipher suite MUST be approved by 457 NIST DRAFT Recommendation for Key Management, Part 3 [NIST SP 458 800-57p3], i.e., the ciphersuite MUST be listed in Table 4-1, 4-2 or 459 4-3 in that document. 461 The mandatory to implement cipher suites MUST NOT include "export 462 strength" cipher suites, cipher suites providing mutually anonymous 463 authentication or static Diffie-Hellman cipher suites. 465 Other ciphersuites MAY be selected following the security 466 requirements for tunnel protocols in NIST DRAFT Recommendation for 467 EAP Methods Used in Wireless Network Access Authentication [NIST SP 468 800-120]. 470 4.2.1.2. Tunnel Replay Protection 472 In order to prevent replay attacks on a tunnel protocol, the message 473 authentication MUST be generated using a time-variant input such as 474 timestamps, sequence numbers, nonces, or a combination of these so 475 that any re-use of the authentication data can be detected as 476 invalid. TLS provides sufficient replay protection to meet this 477 requirements as long as weak cipher suites discussed in Section 6.1 478 are avoided. 480 4.2.1.3. TLS Extensions 482 In order to meet the requirements in this document TLS extensions MAY 483 be used. For example, TLS extensions may be useful in providing 484 certificate revocation information via the TLS OCSP extension (thus 485 meeting the requirement in Section 4.5.1.3). 487 4.2.1.4. Peer Identity Privacy 489 A tunnel protocol MUST support peer privacy. This requires that the 490 username and other attributes associated with the peer are not 491 transmitted in the clear or to an unauthenticated, unauthorized 492 party. Peer identity protection provided by the tunnel method 493 applies to establishment of the tunnel and protection of inner method 494 specific identities. If applicable, the peer certificate is sent 495 confidentially (i.e. encrypted). 497 4.2.1.5. Session Resumption 499 The tunnel method MUST support TLS session resumption as defined in 500 [RFC5246]. The tunnel method MAY support other methods of session 501 resumption such as those defined in [RFC5077]. 503 4.2.2. Fragmentation 505 Tunnel establishment sometimes requires the exchange of information 506 that exceeds what can be carried in a single EAP message. In 507 addition information carried within the tunnel may also exceed this 508 limit. Therefore a tunnel method MUST support fragmentation and 509 reassembly. 511 4.2.3. Protection of Data External to Tunnel 513 A man-in-the-middle attacker can modify clear text values such as 514 protocol version and type code information communicated outside the 515 TLS tunnel. The tunnel method MUST provide implicit or explicit 516 protection of the protocol version and type code. If modification of 517 other information external to the tunnel can cause exploitable 518 vulnerabilities, the tunnel method MUST provide protection against 519 modification of this additional data. 521 4.3. Tunnel Payload Requirements 523 This section describes the payload requirements inside the tunnel. 524 These requirements frequently express features that a candidate 525 protocol must be capable of offering so that a deployer can decide 526 whether to make use of that feature. This section does not state 527 requirements about what features of each protocol must be used during 528 a deployment. 530 4.3.1. Extensible Attribute Types 532 The payload MUST be extensible. Some standard payload attribute 533 types will be defined to meet known requirements listed below, such 534 as password authentication, inner EAP method, vendor specific 535 attributes, and result indication. Additional payload attributes MAY 536 be defined in the future to support additional features and data 537 types. 539 4.3.2. Request/Challenge Response Operation 541 The payload MUST support request and response type of half-duplex 542 operation typical of EAP. Multiple attributes may be sent in a 543 single payload. The payload MAY support carrying on multiple 544 authentications in a single payload packet. 546 4.3.3. Indicating Criticality of Attributes 548 It is expected that new attributes will be defined to be carried 549 within the tunnel method. In some cases it is necessary for the 550 sender to know if the receiver did not understand the attribute. To 551 support this, there MUST be a way for the sender to mark attributes 552 such that the receiver will indicate if an attribute is not 553 understood. 555 4.3.4. Vendor Specific Support 557 The payload MUST support communication of an extensible set of 558 vendor-specific attributes. These attributes will be segmented into 559 uniquely identified vendor specific name spaces. They can be used 560 for experiments or vendor specific features. 562 4.3.5. Result Indication 564 The payload MUST support result indication and its acknowledgement, 565 so both the EAP peer and server will end up with a synchronized 566 state. The result indication is needed after each chained inner 567 authentication method and at the end of the authentication, so 568 separate result indication for intermediate and final result MUST be 569 supported. 571 4.3.6. Internationalization of Display Strings 573 The payload MAY provide a standard attribute format that supports 574 international strings. This attribute format MUST support encoding 575 strings in UTF-8 [RFC3629] format. Any strings sent by the server 576 intended for display to the user MUST be sent in UTF-8 format and 577 SHOULD be able to be marked with language information and adapted to 578 the user's language preference as indicated by RFC 5646 [RFC5646]. 579 Note that in some cases, such as when transmitting error codes, it is 580 acceptable to exchange numeric codes that can be translated by the 581 client to support the particular local language. These numeric codes 582 are not subject internationalization during transmission. 584 4.4. EAP Channel Binding Requirements 586 The tunnel method MUST be capable of meeting EAP channel binding 587 requirements described in [I-D.clancy-emu-chbind]. 589 4.5. Requirements Associated with Carrying Username and Passwords 591 This section describes the requirements associated with tunneled 592 password authentication. The password authentication mentioned here 593 refers to user or machine authentication using a legacy password 594 database or verifier, such as LDAP, OTP, etc. These typically 595 require the password in its original text form in order to 596 authenticate the peer, hence they require the peer to send the clear 597 text user name and password to the EAP server. 599 4.5.1. Security 601 Many internal EAP methods have the peer send its password in the 602 clear to the EAP server. Other methods (e.g. challenge-response 603 methods) are vulnerable to attacks if an eavesdropper can intercept 604 the traffic. For any such methods, the security measures in the 605 following sections MUST be met. 607 4.5.1.1. Confidentiality and Integrity 609 The clear text password exchange MUST be integrity and 610 confidentiality protected. As long as the password exchange occurs 611 inside an authenticated and encrypted tunnel, this requirement is 612 met. 614 4.5.1.2. Authentication of Server 616 The EAP server MUST be authenticated before the peer sends the clear 617 text password to the server. 619 4.5.1.3. Server Certificate Revocation Checking 621 When certificate authentication is used during tunnel establishment 622 the EAP peer may need to present its password to the server before it 623 has network access to check the revocation status of the server's 624 credentials. Therefore, the tunnel method MUST support mechanisms to 625 check the revocation status of a credential. The tunnel method 626 SHOULD make use of Online Certificate Status Protocol (OCSP) 627 [RFC2560] or Server-based Certificate Validation Protocol (SCVP) 628 [RFC5055] to obtain the revocation status of the EAP server 629 certificate. 631 4.5.2. Internationalization 633 The password authentication exchange MUST support user names and 634 passwords in international languages. It MUST support encoding of 635 user name and password strings in UTF-8 [RFC3629] format. The method 636 MUST specify how username and password normalizations and/or 637 comparisons is performed in reference to SASLPrep [RFC4013] or Net- 638 UTF-8 [RFC5198]. 640 Any strings sent by the server intended for display to the user MUST 641 be sent in UTF-8 format and SHOULD be able to be marked with language 642 information and adapted to the user's language preference as 643 indicated by RFC 5646 [RFC5646]. Note that in some cases, such as 644 when transmitting error codes, it is acceptable to exchange numeric 645 codes that can be translated by the client to support the particular 646 local language. These numeric codes are not subject 647 internationalization during transmission. 649 4.5.3. Meta-data 651 The password authentication exchange SHOULD support additional 652 associated meta-data which can be used to indicate whether the 653 authentication is for a user or a machine. This allows the EAP 654 server and peer to request and negotiate authentication specifically 655 for a user or machine. This is useful in the case of multiple inner 656 authentications where the user and machine both need to be 657 authenticated. 659 4.5.4. Password Change 661 The password authentication exchange MUST support password change. 662 The exchange SHOULD be extensible to support other "housekeeping" 663 functions, such as the management of PINs or other data, required by 664 some systems. 666 4.6. Requirements Associated with Carrying EAP Methods 668 The tunnel method MUST be able to carry inner EAP methods without 669 modifying them. EAP methods MUST NOT be redefined inside the tunnel. 671 4.6.1. Method Negotiation 673 The tunnel method MUST support the protected negotiation of the inner 674 EAP method. It MUST NOT allow the inner EAP method negotiation to be 675 manipulated by intermediaries. 677 4.6.2. Chained Methods 679 The tunnel method SHOULD support the chaining of multiple EAP 680 methods. The tunnel method MUST allow for the communication of 681 intermediate result and verification of compound binding between 682 executed inner methods when chained methods are employed. 684 4.6.3. Cryptographic Binding with the TLS Tunnel 686 The tunnel method MUST provide a mechanism to bind the tunnel 687 protocol and the inner EAP method. This property is referred to as 688 cryptographic binding. Such bindings are an important tool for 689 mitigating the tunnel MitM attacks on tunnel methods [TUNNEL-MITM]. 690 Cryptographic bindings enable the complete prevention of tunnel MitM 691 attacks without the need of additional security policies as long as 692 the inner method derives keys and is not vulnerable to attacks 693 outside a protected tunnel [LCN 2010]. Even though weak or non-key 694 deriving inner methods may be permitted, and thus security policies 695 preventing tunnel MitM attacks are still necessary, the tunnel method 696 MUST provide cryptographic bindings, because only this allows 697 migrating to more secure, policy-independent implementations. 699 Cryptographic bindings are typically achieved by securely mixing the 700 established keying material (say tunnel key TK) from the tunnel 701 protocol with the established keying material (say method key MK) 702 from the inner authentication method(s) in order to derive fresh 703 keying material. If chained EAP methods are executed in the tunnel, 704 all derived inner keys are combined with the tunnel key to create a 705 new compound tunnel key (CTK). In particular, CTK is used to derive 706 the EAP MSK, EMSK and other transient keys (TEK), such as transient 707 encryption keys and integrity protection keys. The key hierarchy for 708 tunnel methods executions that derive compound keys for the purpose 709 of cryptographic binding is depicted in Figure 1. 711 In the case of the sequential executions of n inner methods, a 712 chained compound key CTK_i MUST be computed upon the completion of 713 each inner method i such that it contains the compound key of all 714 previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n 715 and CTK_0=TK, where f() is a key derivation function, such as one 716 that complies with NIST Recommendation for Key Derivation Using 717 Pseudorandom Functions [NIST SP 800-108]. CTK_n SHOULD serve as the 718 key to derive further keys. Figure 1 depicts the key hierarchy in 719 the case of a single inner method. Transient keys derived from the 720 compound key CTK are used in a cryptographic protocol to verify the 721 integrity of the tunnel and the inner authentication method. 723 ----------- 724 | TK | MK | 725 ----------- 726 | | 727 v v 728 -------- 729 | CTK | 730 -------- 731 | 732 v 733 ---------------- 734 | | | 735 v v v 736 ------- ------ ------- 737 | TEK | | MSK | | EMSK | 738 ------- ------- -------- 740 Figure 1: Compound Keys 742 Furthermore, all compound keys CTK_i and all keys derived from it 743 SHOULD follow the recommendations for key derivations and key 744 hierarchies as specified in [NIST SP 800-108]. In particular, all 745 derived keys MUST have a lifetime assigned that does not exceed the 746 lifetime of any key higher in the key hierarchy. The derivation MUST 747 prevent a compromise in one part of the system from leading to 748 compromises in other parts of the system that relay on keys at the 749 same or higher level in the hierarchy. 751 4.6.4. Peer Initiated 753 The tunnel method SHOULD allow for the peer to initiate an inner EAP 754 authentication in order to meet its policy requirements for 755 authenticating the server. 757 4.6.5. Method Meta-data 759 The tunnel method SHOULD allow for the communication of additional 760 data associated with an EAP method. This can be used to indicate 761 whether the authentication is for a user or a machine. This allows 762 the EAP server and peer to request and negotiate authentication 763 specifically for a user or machine. This is useful in the case of 764 multiple inner EAP authentications where the user and machine both 765 need to be authenticated. 767 5. IANA Considerations 769 This document has no IANA considerations. 771 6. Security Considerations 773 A tunnel method is often deployed to provide mutual authentication 774 between EAP Peer and EAP Server and to generate key material for use 775 in protecting lower layer protocols. In addition the tunnel is used 776 to protect the communication of additional data, including peer 777 identity between the EAP Peer and EAP Server from disclosure to or 778 modification by an attacker. These sections cover considerations 779 that affect the ability for a method to achieve these goals. 781 6.1. Cipher Suite Selection 783 TLS supports a wide variety of cipher suites providing a variety of 784 security properties. The selection of cipher suites is critical to 785 the security of the tunnel method. Selection of a cipher suite with 786 weak or no authentication, such as an anonymous Diffie- Hellman based 787 cipher suite will greatly increase the risk of system compromise. 788 Since a tunnel method uses the TLS tunnel to transport data, the 789 selection of a ciphersuite with weak data encryption and integrity 790 algorithms will also increase the vulnerability of the method to 791 attacks. 793 A tunnel protocol is prone to downgrading attacks if the tunnel 794 protocol supports any key establishment algorithm that can be broken 795 on-line. In a successful downgrading attack, an adversary breaks the 796 selected "weak" key establishment algorithm and optionally the "weak" 797 authentication algorithm without being detected. Here, "weak" refers 798 to a key establishment algorithm that can be broken in real-time, and 799 an authentication scheme that can be broken off-line, respectively. 800 See [KHLC07] for more details. The requirements in this document 801 disapprove the use of key establishment algorithms that can be broken 802 on-line. 804 Mutually anonymous tunnel protocols are prone to man-in-the-middle 805 attacks described in [KHLC07]. During such an attack, an adversary 806 establishes a tunnel with each the peer and the authentication 807 server, while peer and server believe that they established a tunnel 808 with each other. Once both tunnels have been established, the 809 adversary can eavesdrop on all communications within the tunnels, 810 i.e. the execution of the inner authentication method(s). 811 Consequently, the adversary can eavesdrop on the identifiers that are 812 exchanged as part of the EAP method and thus, the privacy of peer 813 and/or authentication server is compromised along with any other data 814 transmitted within the tunnels. This document requires server 815 authentication to avoid the risks associated with anonymous cipher 816 suites. 818 6.2. Tunneled Authentication 820 In many cases a tunnel method provides mutual authentication by 821 authenticating the server during tunnel establishment and 822 authenticating the peer within the tunnel using an EAP method. As 823 described in [TUNNEL-MITM], this mode of operation can allow tunnel 824 man-in-the-middle attackers to authenticate to the server as the peer 825 by tunneling the inner EAP protocol messages to and from a peer 826 executing the method outside a tunnel or with an untrustworthy 827 server. Cryptographic binding between the established keying 828 material from the inner authentication method(s) and the tunnel 829 protocol verifies that the endpoints of the tunnel and the inner 830 authentication method(s) are the same. This can thwart the attack if 831 the inner method derived keys of sufficient strength that they cannot 832 be broken in real-time. 834 In cases where the inner authentication method does not generate any 835 or only weak key material, security policies must be enforced such 836 that the peer cannot execute the inner method with the same 837 credentials outside a protective tunnel or with an untrustworthy 838 server. 840 6.3. Data External to Tunnel 842 The tunnel method will use data that is outside the TLS tunnel such 843 as the EAP type code or version numbers. If an attacker can 844 compromise the protocol by modifying these values the tunnel method 845 MUST protect this data from modification. In some cases external 846 data may not need additional protection because it is implicitly 847 verified during the protocol operation. 849 6.4. Separation of TLS Tunnel and Inner Authentication Termination 851 Terminating the inner method at a different location than the outer 852 tunnel needs careful consideration. The inner method data may be 853 vulnerable to modification and eavesdropping between the server that 854 terminates the tunnel and the server that terminates the inner 855 method. For example if a clear text password is used then it may be 856 sent to the inner method server in a RADIUS password attribute which 857 uses weak encryption that may not be suitable protection for many 858 environments. 860 In some cases terminating the tunnel at a different location may make 861 it difficult for a peer to authenticate the server and trust it for 862 further communication. For example, if the TLS tunnel is terminated 863 by a different organization the peer needs to be able to authenticate 864 and authorize the tunnel server to handle secret credentials that it 865 shares with the home server that terminates the inner method. This 866 may not meet the security policy of many environments. 868 7. References 870 7.1. Normative References 872 [I-D.clancy-emu-chbind] 873 Clancy, C. and K. Hoeper, "Channel Binding Support for EAP 874 Methods", draft-clancy-emu-chbind-04 (work in progress), 875 November 2008. 877 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 878 Adams, "X.509 Internet Public Key Infrastructure Online 879 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 881 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 882 10646", STD 63, RFC 3629, November 2003. 884 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 885 Levkowetz, "Extensible Authentication Protocol (EAP)", 886 RFC 3748, June 2004. 888 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 889 Authentication Protocol (EAP) Method Requirements for 890 Wireless LANs", RFC 4017, March 2005. 892 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 893 Authorization, and Accounting (AAA) Key Management", 894 BCP 132, RFC 4962, July 2007. 896 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 897 Polk, "Server-Based Certificate Validation Protocol 898 (SCVP)", RFC 5055, December 2007. 900 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 901 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 903 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 904 Authentication Protocol (EAP) Key Management Framework", 905 RFC 5247, August 2008. 907 7.2. Informative References 909 [I-D.mahy-eap-enrollment] 910 Mahy, R., "An Extensible Authentication Protocol (EAP) 911 Enrollment Method", draft-mahy-eap-enrollment-01 (work in 912 progress), March 2006. 914 [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 915 ICST QShine , August 2007. 917 [LCN 2010] 918 Hoeper, K. and L. Chen, "An Inconvenient Truth about 919 Tunneled Authentications", Proceedings of 35th Annual IEEE 920 Conference on Local Computer Networks (LCN 2010) , 921 September 2009. 923 [NIST SP 800-108] 924 Chen, L., "Recommendation for Key Derivation Using 925 Pseudorandom Functions", Draft NIST Special 926 Publication 800-108, April 2008. 928 [NIST SP 800-120] 929 Hoeper, K. and L. Chen, "Recommendation for EAP Methods 930 Used in Wireless Network Access Authentication", NIST 931 Special Publication 800-120, September 2009. 933 [NIST SP 800-57] 934 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 935 "Recommendation for Key Management - Part 1: General 936 (Revised)", NIST Special Publication 800-57, part 1, 937 March 2007. 939 [NIST SP 800-57p3] 940 Barker, E., Burr, W., Jones, A., Polk, W., , S., and M. 941 Smid, "Recommendation for Key Management, Part 3 942 Application-Specific Key Management Guidance", Draft NIST 943 Special Publication 800-57,part 3, October 2008. 945 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 946 Authentication Protocol (PEAP) Specification", 947 August 2009. 949 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 950 and Passwords", RFC 4013, February 2005. 952 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 953 Network Access Identifier", RFC 4282, December 2005. 955 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 956 Flexible Authentication via Secure Tunneling Extensible 957 Authentication Protocol Method (EAP-FAST)", RFC 4851, 958 May 2007. 960 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 961 "Transport Layer Security (TLS) Session Resumption without 962 Server-Side State", RFC 5077, January 2008. 964 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 965 Interchange", RFC 5198, March 2008. 967 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 968 Tardo, "Network Endpoint Assessment (NEA): Overview and 969 Requirements", RFC 5209, June 2008. 971 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 972 Protocol Tunneled Transport Layer Security Authenticated 973 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 975 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 976 Languages", BCP 47, RFC 5646, September 2009. 978 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 979 A Posture Broker (PB) Protocol Compatible with Trusted 980 Network Connect (TNC)", RFC 5793, March 2010. 982 [TUNNEL-MITM] 983 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 984 in Tunnelled Authentication Protocols", Cryptology ePrint 985 Archive: Report 2002/163, November 2002. 987 Appendix A. Changes from -01 988 o Added combined mutual authentication in section 3.1 989 o Changed reference from SP 800-52 to SP 800-57,part 3 990 o In section 6.2 changed terminology to tunnel MitM and security 991 policy enforcement 992 o Reworded text in section 3.2 to clarify MITM protection 993 o Added more specific text about derivation of the CTK 994 o Removed resource constrained section 995 o Added support for Non EAP authentication as a use for 996 extensibility 997 o Added text to emergency services section to emphasize that 998 sensitive information should not be sent if the server is 999 unauthenticated. 1000 o Reworded TLS requirements 1001 o Reworded external data protection requirements 1002 o Added text to section 4.6 that states method must not be re- 1003 defined inside the tunnel. 1004 o Editorial fixes 1006 Appendix B. Changes from -02 1007 o Editorial Fixes 1008 o Clarified client authentication during tunnel establishment 1009 o Changed text so that the tunnel method MUST meet all MUST and 1010 SHOULD requirements relevant to EAP methods in RFCs 4962 and 5247 1012 Appendix C. changes from -03 1013 o Resolution of open issues: 1014 http://trac.tools.ietf.org/wg/emu/trac/report/9 1015 o Revised section 2 to match other similar RFC(Issue 6) 1016 o Cleaned up section 3.2 (issue 8) 1017 o Clarified identity protection scope in section 3.4 and 1018 4.2.1.4(issue 9) 1019 o Changed Emergency Services to anonymous authentication(section 1020 3.5)(issue 10) 1021 o Clarified section 4.1.1 (issue 15) 1022 o Cleaned up TLS requirements in section 4.2.1(issue 11) 1023 o Replaced text in 4.2.1.1.3 with suitable reference 1024 o Improved wording in 4.2.3 and 6.3 (issue 13) 1025 o Update internationalization requirements in 4.3.6 and 4.5.2 1026 (Issues 25,18) 1027 o Updated text in 4.5.1 (issue 16) 1028 o Changed meta-data to SHOULD in 4.5.3 and 4.6.5(Issue 20) 1029 o Changed chained methods to SHOULD in 4.6.2(issue 19) 1030 o Added security consideration for inner method termination(issue 1031 24) 1032 o Updated references 1033 o Editorial changes(issues 7,22,17) 1035 Authors' Addresses 1037 Katrin Hoeper 1038 Motorola, Inc. 1039 1301 E Algonquin Rd 1040 Schaumburg, IL 60196 1041 USA 1043 Email: khoeper@motorola.com 1045 Stephen Hanna 1046 Juniper Networks 1047 3 Beverly Road 1048 Bedford, MA 01730 1049 USA 1051 Email: shanna@juniper.net 1053 Hao Zhou 1054 Cisco Systems, Inc. 1055 4125 Highlander Parkway 1056 Richfield, OH 44286 1057 USA 1059 Email: hzhou@cisco.com 1061 Joseph Salowey (editor) 1062 Cisco Systems, Inc. 1063 2901 3rd. Ave 1064 Seattle, WA 98121 1065 USA 1067 Email: jsalowey@cisco.com