idnits 2.17.1 draft-ietf-emu-eaptunnel-req-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 172: '... MUST - indicates an absolute req...' RFC 2119 keyword, line 174: '... MUST NOT - indicates something a...' RFC 2119 keyword, line 176: '... SHOULD - indicates a strong reco...' RFC 2119 keyword, line 178: '... SHOULD NOT - indicates a strong ...' RFC 2119 keyword, line 180: '... MAY - indicates a willingness to...' (106 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 (March 8, 2010) is 5163 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 4646 (Obsoleted by RFC 5646) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: September 9, 2010 Juniper Networks 6 H. Zhou 7 J. Salowey, Ed. 8 Cisco Systems, Inc. 9 March 8, 2010 11 Requirements for a Tunnel Based EAP Method 12 draft-ietf-emu-eaptunnel-req-05.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 to IETF 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), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 9, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Conventions Used In This Document . . . . . . . . . . . . . . 5 78 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 80 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 81 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 82 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 83 3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7 84 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 85 3.7. Client Authentication During Tunnel Establishment . . . . 8 86 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 88 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9 90 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9 91 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9 92 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 93 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 94 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 95 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 96 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10 97 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 98 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11 99 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11 100 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 101 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 102 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 103 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 104 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 105 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12 106 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 107 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13 108 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 14 109 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 14 110 4.3.6. Internationalization of Display Strings . . . . . . . 14 111 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 112 4.5. Requirements Associated with Carrying Username and 113 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 114 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 115 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15 116 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 117 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 118 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 119 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 16 120 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16 121 4.6. Requirements Associated with Carrying EAP Methods . . . . 16 122 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 123 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 124 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16 125 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 18 126 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 128 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 130 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 131 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18 132 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 133 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20 134 6.4. Separation of TLS Tunnel and Inner Authentication 135 Termination . . . . . . . . . . . . . . . . . . . . . . . 20 137 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 138 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 139 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 141 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 23 143 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23 145 Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 149 1. Introduction 151 Running EAP methods within a TLS protected tunnel has been deployed 152 in several different solutions. EAP methods supporting this include 153 PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this 154 has worked well so there is consensus to continue to use TLS as the 155 basis for a tunnel method. There have been various reasons for 156 employing a protected tunnel for EAP processes. They include 157 protecting weak authentication exchanges, such as username and 158 password. In addition a protected tunnel can provide means to 159 provide peer identity protection and EAP method chaining. Finally, 160 systems have found it useful to transport additional types of data 161 within the protected tunnel. 163 This document describes the requirements for an EAP tunnel method as 164 well as for a password protocol supporting legacy password 165 verification within the tunnel method. 167 2. Conventions Used In This Document 169 Use of each capitalized word within a sentence or phrase carries the 170 following meaning during the EMU WG's method selection process: 172 MUST - indicates an absolute requirement 174 MUST NOT - indicates something absolutely prohibited 176 SHOULD - indicates a strong recommendation of a desired result 178 SHOULD NOT - indicates a strong recommendation against a result 180 MAY - indicates a willingness to allow an optional outcome 182 Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 183 "MAY" carry their normal meaning and are not subject to these 184 definitions. 186 3. Use Cases 188 To motivate and explain the requirements in this document, a 189 representative set of use cases for the EAP tunnel method are 190 supplied here. The candidate tunnel method needs to support all of 191 the use cases that are marked below as "MUST". 193 3.1. Password Authentication 195 Many legacy systems only support user authentication with passwords. 196 Some of these systems require transport of the actual username and 197 password to the authentication server. This is true for systems 198 where the authentication server does not have access to the cleartext 199 password or a consistent transform of the cleartext password. 200 Example of such systems are one time password (OTP) systems and other 201 systems where the username and password are submitted to an external 202 party for validation. The tunnel method MUST support transporting 203 cleartext username and password to the EAP server. It MUST NOT 204 reveal information about the username and password to parties in the 205 communication path between the peer and the EAP Server. The 206 advantage any attacker gains against the tunneled method when 207 employing a username and password for authentication MUST be through 208 interaction and not computation. The tunnel MUST provide protection 209 from man-in-the-middle attacks. The combination of the tunnel 210 authentication and password authentication MUST enable mutual 211 authentication. 213 Since EAP authentication occurs before network access is granted the 214 tunnel method SHOULD enable an inner exchange to provide support for 215 minimal password management tasks including password change, "new PIN 216 mode", and "next token mode" required by some systems. 218 3.2. Protection of Weak EAP Methods 220 Some existing EAP methods have vulnerabilities that could be 221 eliminated or reduced by running them inside a protected tunnel. For 222 example, a EAP-MD5 does not provide mutual authentication or 223 protection from dictionary attacks. Without extra protection, 224 tunnel-based EAP methods are vulnerable to a special type of tunnel 225 man-in-the-middle attack [TUNNEL-MITM]. This attack is referred to 226 as "tunnel MitM attack" in the remainder of this document. The 227 additional protection needed to thwart tunnel MitM attacks depends on 228 the inner method executed within the tunnel. When weak methods are 229 used, these attacks can be mitigated via security policies that 230 require the method to be used only within a tunnel. On the other 231 hand, a technical solution (so-called cryptographic bindings) can be 232 used whenever the inner method derives key material and is not 233 susceptible to attacks outside a tunnel. Only the latter mitigation 234 technique can be made an actual requirement for tunnel-based EAP 235 methods (see Section 4.6.3), while security policies are outside the 236 scope of this requirement draft. Please refer to the NIST 237 Recommendation for EAP Methods Used in Wireless Network Access 238 Authentication [NIST SP 800-120] for a discussion on security 239 policies and complete solutions for thwarting tunnel MitM attacks. 241 The tunnel method MUST support protection of weak EAP methods. 242 Cryptographic protection from tunnel MitM attacks MUST be provided 243 for all key generating methods. In combination with an appropriate 244 security policy this will thwart MitM attacks against inner methods. 246 3.3. Chained EAP Methods 248 Several circumstances are best addressed by using chained EAP 249 methods. For example, it may be desirable to authenticate the user 250 and also authenticate the device being used. However, chained EAP 251 methods from different conversations can be re-directed into the same 252 conversation by an attacker giving the authenticator the impression 253 that both conversations terminate at the same end-point. 254 Cryptographic binding can be used to bind the results of chained key 255 generating methods together or to an encompassing tunnel. 257 The tunnel method MUST support chained EAP methods while including 258 strong protection against attacks on method chaining. 260 3.4. Identity Protection 262 When performing an EAP authentication, the peer may want to protect 263 its identity and only disclose it to a trusted EAP server. This 264 helps to maintain peer privacy. 266 The tunnel method MUST support identity protection, therefore the 267 identity of the peer used for authentication purposes MUST NOT be 268 obtainable by any entity other than the EAP server terminating the 269 tunnel method. Peer identity protection provided by the tunnel 270 method applies to tunnel method and inner method specific identities. 271 Note that the peer may need to expose the realm portion of the EAP 272 outer identity in the NAI [RFC4282] in a roaming scenario in order to 273 reach the appropriate authentication server. 275 3.5. Anonymous Service Access 277 When network service is provided, it is sometimes desirable for a 278 user to gain network access in order to access limited services for 279 emergency communication or troubleshooting information. To avoid 280 eavesdropping, it's best to negotiate link layer security as with any 281 other authentication. 283 Therefore, the tunnel method SHOULD allow anonymous peers or server- 284 only authentication, while still deriving keys that can be used for 285 link layer security. The tunnel method MAY also allow for the bypass 286 of server authentication processing on the client. 288 Forgoing user or server authentication increases the chance of man- 289 in-the-middle and other types of attacks that can compromise the 290 derived keys used for link layer security. Therefore, passwords and 291 other sensitive information MUST NOT be disclosed to an 292 unauthenticated server, or to a server that is not authorized to 293 authenticate the user. 295 3.6. Network Endpoint Assessment 297 The Network Endpoint Assessment (NEA) protocols and reference model 298 described in [RFC5209] provide a standard way to check the health 299 ("posture") of a device at or after the time it connects to a 300 network. If the device does not comply with the network's 301 requirements, it can be denied access to the network or granted 302 limited access to remediate itself. EAP is a convenient place for 303 conducting an NEA exchange. 305 The tunnel method SHOULD support carrying NEA protocols such as PB- 306 TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel 307 method, these protocols may be required to be carried in an EAP 308 method. 310 3.7. Client Authentication During Tunnel Establishment 312 In some cases the peer will have credentials that allow it to 313 authenticate during tunnel establishment. These credentials may only 314 partially authenticate the identity of the peer and additional 315 authentication may be required inside the tunnel. For example, a 316 communication device may be authenticated during tunnel 317 establishment, in addition user authentication may be required to 318 satisfy authentication policy. The tunnel method MUST be capable of 319 providing client side authentication during tunnel establishment. 321 3.8. Extensibility 323 The tunnel method MUST provide extensibility so that additional data 324 related to authentication, authorization and network access can be 325 carried inside the tunnel in the future. This removes the need to 326 develop new tunneling methods for specific purposes. 328 An application for extensibility is credential provisioning. When a 329 peer has authenticated with EAP, this is a convenient time to 330 distribute credentials to that peer that may be used for later 331 authentication exchanges. For example, the authentication server can 332 provide a private key or shared key to the peer that can be used by 333 the peer to perform rapid re-authentication or roaming. In addition 334 there have been proposals to perform enrollment within EAP, such as 335 [I-D.mahy-eap-enrollment]. Another use for extensibility is support 336 for alternate authentication frameworks within the tunnel. 338 4. Requirements 340 4.1. General Requirements 342 4.1.1. RFC Compliance 344 The tunnel method MUST include a Security Claims section with all 345 security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In 346 addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 347 3748 that tunnel methods MUST support protection against man-in-the- 348 middle attacks. Furthermore, the tunnel method MUST support identity 349 protection as specified in Section 7.3 in RFC 3748. 351 The tunnel method MUST be unconditionally compliant with RFC 4017 352 [RFC4017] (using the definition of "unconditionally compliant" 353 contained in section 1.1 of RFC 4017). This means that the method 354 MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT 355 requirements in RFC 4017. 357 The tunnel method MUST meet all the MUST and SHOULD requirements 358 relevant to EAP methods contained in the EAP Key Management Framework 359 [RFC5247] or any successor. This includes the generation of the MSK, 360 EMSK, Peer-Id, Server-Id and Session-Id. These requirements will 361 enable the tunnel method to properly fit into the EAP key management 362 framework, maintaining all of the security properties and guarantees 363 of that framework. 365 The tunnel method MUST NOT be tied to any single cryptographic 366 algorithm. Instead, it MUST support run-time negotiation to select 367 among an extensible set of cryptographic algorithms, such as 368 algorithms used with certificates presented during tunnel 369 establishment. This "cryptographic algorithm agility" provides 370 several advantages. Most important, when a weakness in an algorithm 371 is discovered or increased processing power overtakes an algorithm, 372 users can easily transition to a new algorithm. Also, users can 373 choose the algorithm that best meets their needs. 375 The tunnel method MUST meet the SHOULD and MUST requirements 376 pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. 377 This includes: cryptographic algorithm independence; strong, fresh 378 session keys; replay detection; keying material confidentiality and 379 integrity; and confirmation of cipher suite selection. 381 4.1.2. Draw from Existing Work 383 Several existing tunnel methods are already in widespread usage: EAP- 384 FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable 385 experience has been gained from various deployments with these 386 methods. This experience SHOULD be considered when evaluating tunnel 387 methods. If one of these existing tunnel methods can meet the 388 requirements contained in this specification then that method SHOULD 389 be preferred over a new method. 391 Even if minor modifications or extensions to an existing tunnel 392 method are needed, this method SHOULD be preferred over a completely 393 new method so that the advantage of accumulated deployment experience 394 and security analysis can be gained. 396 4.2. Tunnel Requirements 398 The following section discusses requirements for TLS Tunnel 399 Establishment. 401 4.2.1. TLS Requirements 403 The tunnel based method MUST support TLS version 1.2 [RFC5246] and 404 may support earlier versions to enable the possibility of backwards 405 compatibility. 407 4.2.1.1. Cipher Suites 409 4.2.1.1.1. Cipher Suite Negotiation 411 Cipher suite negotiations always suffer from downgrading attacks when 412 they are not secured by any kind of integrity protection. A common 413 practice is a post integrity check in which, as soon as available, 414 the established keys (here the tunnel key) are used to derive 415 integrity keys. These integrity keys are then used by peer and 416 authentication server to verify whether the cipher suite negotiation 417 has been maliciously altered by another party. 419 Integrity checks prevent downgrading attacks only if the derived 420 integrity keys and the employed integrity algorithms cannot be broken 421 in real-time. See Section 6.1 or [KHLC07] for more information on 422 this. Hence, the tunnel method MUST provide integrity protected 423 cipher suite negotiation with secure integrity algorithms and 424 integrity keys. 426 TLS provides protected cipher suite negotiation as long as all the 427 cipher suites supported provide strong authentication, key 428 establishment and data integrity protection. 430 4.2.1.1.2. Tunnel Data Protection Algorithms 432 In order to prevent attacks on the cryptographic algorithms employed 433 by inner authentication methods, a tunnel protocol's protection needs 434 to provide a basic level of algorithm strength. The tunnel method 435 MUST provide at least one mandatory to implement cipher suite that 436 provides the equivalent security of 128-bit AES for encryption and 437 message authentication. See Part 1 of the NIST Recommendation for 438 Key Management [NIST SP 800-57] for a discussion of the relative 439 strengths of common algorithms. 441 4.2.1.1.3. Tunnel Authentication and Key Establishment 443 A tunnel method MUST provide unidirectional authentication from 444 authentication server to EAP peer and mutual authentication between 445 authentication server and EAP peer. The tunnel method MUST provide 446 at least one mandatory to implement cipher suite that provides 447 certificate-based authentication of the server and provides optional 448 certificate-based authentication of the client. Other types of 449 authentication MAY be supported. 451 At least one mandatory to implement cipher suite MUST be approved by 452 NIST DRAFT Recommendation for Key Management, Part 3 [NIST SP 453 800-57p3], i.e., the ciphersuite MUST be listed in Table 4-1, 4-2 or 454 4-3 in that document. 456 The mandatory to implement cipher suites MUST NOT include "export 457 strength" cipher suites, cipher suites providing mutually anonymous 458 authentication or static Diffie-Hellman cipher suites. 460 Other ciphersuites MAY be selected following the security 461 requirements for tunnel protocols in NIST DRAFT Recommendation for 462 EAP Methods Used in Wireless Network Access Authentication [NIST SP 463 800-120]. 465 4.2.1.2. Tunnel Replay Protection 467 In order to prevent replay attacks on a tunnel protocol, the message 468 authentication MUST be generated using a time-variant input such as 469 timestamps, sequence numbers, nonces, or a combination of these so 470 that any re-use of the authentication data can be detected as 471 invalid. TLS provides sufficient replay protection to meet this 472 requirements as long as strong ciphersuites are used. 474 4.2.1.3. TLS Extensions 476 In order to meet the requirements in this document TLS extensions MAY 477 be used. For example, TLS extensions may be useful in providing 478 certificate revocation information via the TLS OCSP extension (thus 479 meeting the requirement in Section 4.5.1.3). 481 4.2.1.4. Peer Identity Privacy 483 A tunnel protocol MUST support peer privacy. This requires that the 484 username and other attributes associated with the peer are not 485 transmitted in the clear or to an unauthenticated, unauthorized 486 party. Peer identity protection provided by the tunnel method 487 applies to establishment of the tunnel and protection of inner method 488 specific identities. If applicable, the peer certificate is sent 489 confidentially (i.e. encrypted). 491 4.2.1.5. Session Resumption 493 The tunnel method MUST support TLS session resumption as defined in 494 [RFC5246]. The tunnel method MAY support other methods of session 495 resumption such as those defined in [RFC5077]. 497 4.2.2. Fragmentation 499 Tunnel establishment sometimes requires the exchange of information 500 that exceeds what can be carried in a single EAP message. In 501 addition information carried within the tunnel may also exceed this 502 limit. Therefore a tunnel method MUST support fragmentation and 503 reassembly. 505 4.2.3. Protection of Data External to Tunnel 507 A man-in-the-middle attacker can modify clear text values such as 508 protocol version and type code information communicated outside the 509 TLS tunnel. The tunnel method MUST provide implicit or explicit 510 protection of the protocol version and type code. If modification of 511 other information external to the tunnel can cause exploitable 512 vulnerabilities, the tunnel method MUST provide protection against 513 modification of this additional data. 515 4.3. Tunnel Payload Requirements 517 This section describes the payload requirements inside the tunnel. 518 These requirements frequently express features that a candidate 519 protocol must be capable of offering so that a deployer can decide 520 whether to make use of that feature. This section does not state 521 requirements about what features of each protocol must be used during 522 a deployment. 524 4.3.1. Extensible Attribute Types 526 The payload MUST be extensible. Some standard payload attribute 527 types will be defined to meet known requirements listed below, such 528 as password authentication, inner EAP method, vendor specific 529 attributes, and result indication. Additional payload attributes MAY 530 be defined in the future to support additional features and data 531 types. 533 4.3.2. Request/Challenge Response Operation 535 The payload MUST support request and response type of half-duplex 536 operation typical of EAP. Multiple attributes may be sent in a 537 single payload. The payload MAY support carrying on multiple 538 authentications in a single payload packet. 540 4.3.3. Mandatory and Optional Attributes 542 The payload MUST support marking of mandatory and optional 543 attributes, as well as an attribute used for rejecting mandatory 544 attributes. Mandatory attributes are attributes sent by the 545 requester that the responder is expected to understand and MUST 546 respond to. If the responder does not understand or support one of 547 the mandatory attributes in the request, it MUST ignore the rest of 548 the attributes and send a NAK attribute to decline the request. The 549 NAK attribute MUST support inclusion of which mandatory attribute is 550 not supported. The optional attributes are attributes that are not 551 mandatory to support and respond to. If the responder does not 552 understand or support the optional attributes, it can ignore these 553 attributes. 555 The payload MUST support marking of mandatory and optional 556 attributes, as well as a "NAK" attribute used to communicate 557 disagreements about received attributes. 559 Mandatory attributes are attributes that a receiver MUST process as 560 per the specification. Optional attributes are attributes that a 561 receiver MAY ignore. 563 A receiver MUST process mandatory attributes before optional ones. 564 After an attribute has been processed, it SHOULD be marked as no 565 longer being mandatory. If a receiver does not process a mandatory 566 attribute, it MUST ignore everything else in a request, and it MUST 567 send a NAK attribute in response. Similarly, if a receiver expects a 568 mandatory attribute and does not receive one in a request, it MUST 569 send a NAK attribute in the response that contains the set of 570 attributes it expected to receive. 572 The NAK attribute MUST support a description of which mandatory 573 attribute is either required, or is not supported. The NAK attribute 574 MUST be otherwise treated as an optional attribute, and it MUST NOT 575 contain a NAK of the NAK attribute, in order to prevent infinite 576 recursion. 578 4.3.4. Vendor Specific Support 580 The payload MUST support communication of an extensible set of 581 vendor-specific attributes. These attributes will be segmented into 582 uniquely identified vendor specific name spaces. They can be used 583 for experiments or vendor specific features. 585 4.3.5. Result Indication 587 The payload MUST support result indication and its acknowledgement, 588 so both the EAP peer and server will end up with a synchronized 589 state. The result indication is needed after each chained inner 590 authentication method and at the end of the authentication, so 591 separate result indication for intermediate and final result MUST be 592 supported. 594 4.3.6. Internationalization of Display Strings 596 The payload MAY provide a standard attribute format that supports 597 international strings. This attribute format MUST support encoding 598 strings in UTF-8 [RFC3629] format. Any strings sent by the server 599 intended for display to the user MUST be sent in UTF-8 format and 600 SHOULD be able to be marked with language information and adapted to 601 the user's language preference as indicated by RFC 4646 [RFC4646]. 602 Note that in some cases, such as when transmitting error codes, it is 603 acceptable to exchange numeric codes that can be translated by the 604 client to support the particular local language. These numeric codes 605 are not subject internationalization during transmission. 607 4.4. EAP Channel Binding Requirements 609 The tunnel method MUST be capable of meeting EAP channel binding 610 requirements described in [I-D.clancy-emu-chbind]. 612 4.5. Requirements Associated with Carrying Username and Passwords 614 This section describes the requirements associated with tunneled 615 password authentication. The password authentication mentioned here 616 refers to user or machine authentication using a legacy password 617 database or verifier, such as LDAP, OTP, etc. These typically 618 require the password in its original text form in order to 619 authenticate the peer, hence they require the peer to send the clear 620 text user name and password to the EAP server. 622 4.5.1. Security 624 Many internal EAP methods have the peer send its password in the 625 clear to the EAP server. Other methods (e.g. challenge-response 626 methods) are vulnerable to attacks if an eavesdropper can intercept 627 the traffic. For any such methods, the security measures in the 628 following sections MUST be met. 630 4.5.1.1. Confidentiality and Integrity 632 The clear text password exchange MUST be integrity and 633 confidentiality protected. As long as the password exchange occurs 634 inside an authenticated and encrypted tunnel, this requirement is 635 met. 637 4.5.1.2. Authentication of Server 639 The EAP server MUST be authenticated before the peer sends the clear 640 text password to the server. 642 4.5.1.3. Server Certificate Revocation Checking 644 When certificate authentication is used during tunnel establishment 645 the EAP peer may need to present its password to the server before it 646 has network access to check the revocation status of the server's 647 credentials. Therefore, the tunnel method MUST support mechanisms to 648 check the revocation status of a credential. The tunnel method 649 SHOULD make use of Online Certificate Status Protocol (OCSP) 650 [RFC2560] or Server-based Certificate Validation Protocol (SCVP) 651 [RFC5055] to obtain the revocation status of the EAP server 652 certificate. 654 4.5.2. Internationalization 656 The password authentication exchange MUST support user names and 657 passwords in international languages. It MUST support encoding of 658 user name and password strings in UTF-8 [RFC3629] format. The method 659 MUST specify how username and password normalizations and/or 660 comparisons is performed in reference to SASLPrep [RFC4013] or Net- 661 UTF-8 [RFC5198]. 663 Any strings sent by the server intended for display to the user MUST 664 be sent in UTF-8 format and SHOULD be able to be marked with language 665 information and adapted to the user's language preference as 666 indicated by RFC 4646 [RFC4646]. Note that in some cases, such as 667 when transmitting error codes, it is acceptable to exchange numeric 668 codes that can be translated by the client to support the particular 669 local language. These numeric codes are not subject 670 internationalization during transmission. 672 4.5.3. Meta-data 674 The password authentication exchange SHOULD support additional 675 associated meta-data which can be used to indicate whether the 676 authentication is for a user or a machine. This allows the EAP 677 server and peer to request and negotiate authentication specifically 678 for a user or machine. This is useful in the case of multiple inner 679 authentications where the user and machine both need to be 680 authenticated. 682 4.5.4. Password Change 684 The password authentication exchange MUST support password change. 685 The exchange SHOULD be extensible to support other "housekeeping" 686 functions, such as the management of PINs or other data, required by 687 some systems. 689 4.6. Requirements Associated with Carrying EAP Methods 691 The tunnel method MUST be able to carry inner EAP methods without 692 modifying them. EAP methods MUST NOT be redefined inside the tunnel. 694 4.6.1. Method Negotiation 696 The tunnel method MUST support the protected negotiation of the inner 697 EAP method. It MUST NOT allow the inner EAP method negotiation to be 698 manipulated by intermediaries. 700 4.6.2. Chained Methods 702 The tunnel method SHOULD support the chaining of multiple EAP 703 methods. The tunnel method MUST allow for the communication of 704 intermediate result and verification of compound binding between 705 executed inner methods when chained methods are employed. 707 4.6.3. Cryptographic Binding with the TLS Tunnel 709 The tunnel method MUST provide a mechanism to bind the tunnel 710 protocol and the inner EAP method. This property is referred to as 711 cryptographic binding. Such bindings are an important tool for 712 mitigating the tunnel MitM attacks on tunnel methods [TUNNEL-MITM]. 713 Cryptographic bindings enable the complete prevention of tunnel MitM 714 attacks without the need of additional security policies as long as 715 the inner method derives keys and is not vulnerable to attacks 716 outside a protected tunnel [KHLC07]. Even though weak or non-key 717 deriving inner methods may be permitted, and thus security policies 718 preventing tunnel MitM attacks are still necessary, the tunnel method 719 MUST provide cryptographic bindings, because only this allows 720 migrating to more secure, policy-independent implementations. 722 Cryptographic bindings are typically achieved by securely mixing the 723 established keying material (say tunnel key TK) from the tunnel 724 protocol with the established keying material (say method key MK) 725 from the inner authentication method(s) in order to derive fresh 726 keying material. If chained EAP methods are executed in the tunnel, 727 all derived inner keys are combined with the tunnel key to create a 728 new compound tunnel key (CTK). In particular, CTK is used to derive 729 the EAP MSK, EMSK and other transient keys (TEK), such as transient 730 encryption keys and integrity protection keys. The key hierarchy for 731 tunnel methods executions that derive compound keys for the purpose 732 of cryptographic binding is depicted in Figure 1. 734 In the case of the sequential executions of n inner methods, a 735 chained compound key CTK_i MUST be computed upon the completion of 736 each inner method i such that it contains the compound key of all 737 previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n 738 and CTK_0=TK, where f() is a good key derivation function, such as 739 one that complies with NIST Recommendation for Key Derivation Using 740 Pseudorandom Functions [NIST SP 800-108]. CTK_n SHOULD serve as the 741 key to derive further keys. Figure 1 depicts the key hierarchy in 742 the case of a single inner method. Transient keys derived from the 743 compound key CTK are used in a cryptographic protocol to verify the 744 integrity of the tunnel and the inner authentication method. 746 ----------- 747 | TK | MK | 748 ----------- 749 | | 750 v v 751 -------- 752 | CTK | 753 -------- 754 | 755 v 756 ---------------- 757 | | | 758 v v v 759 ------- ------ ------- 760 | TEK | | MSK | | EMSK | 761 ------- ------- -------- 763 Figure 1: Compound Keys 765 Furthermore, all compound keys CTK_i and all keys derived from it 766 SHOULD be derived in accordance to the guidelines for key derivations 767 and key hierarchies as specified in Section 4.2.1.1.3. In 768 particular, all derived keys MUST have a lifetime assigned that does 769 not exceed the lifetime of any key higher in the key hierarchy. The 770 derivation MUST prevent a compromise in one part of the system from 771 leading to compromises in other parts of the system that relay on 772 keys at the same or higher level in the hierarchy. 774 4.6.4. Peer Initiated 776 The tunnel method SHOULD allow for the peer to initiate an inner EAP 777 authentication in order to meet its policy requirements for 778 authenticating the server. 780 4.6.5. Method Meta-data 782 The tunnel method SHOULD allow for the communication of additional 783 data associated with an EAP method. This can be used to indicate 784 whether the authentication is for a user or a machine. This allows 785 the EAP server and peer to request and negotiate authentication 786 specifically for a user or machine. This is useful in the case of 787 multiple inner EAP authentications where the user and machine both 788 need to be authenticated. 790 5. IANA Considerations 792 This document has no IANA considerations. 794 6. Security Considerations 796 A tunnel method is often deployed to provide mutual authentication 797 between EAP Peer and EAP Server and to generate strong key material 798 for use in protecting lower layer protocols. In addition the tunnel 799 is used to protect the communication of additional data, including 800 peer identity between the EAP Peer and EAP Server from disclosure to 801 or modification by an attacker. These sections cover considerations 802 that affect the ability for a method to achieve these goals. 804 6.1. Cipher Suite Selection 806 TLS supports a wide variety of cipher suites providing a variety of 807 security properties. The selection of strong cipher suites is 808 critical to the security of the tunnel method. Selection of a cipher 809 suite with weak or no authentication, such as an anonymous Diffie- 810 Hellman based cipher suite will greatly increase the risk of system 811 compromise. Since a tunnel method uses the TLS tunnel to transport 812 data, the selection of a ciphersuite with weak data encryption and 813 integrity algorithms will also increase the vulnerability of the 814 method to attacks. 816 A tunnel protocol is prone to downgrading attacks if the tunnel 817 protocol supports any key establishment algorithm that can be broken 818 on-line. In a successful downgrading attack, an adversary breaks the 819 selected "weak" key establishment algorithm and optionally the "weak" 820 authentication algorithm without being detected. Here, "weak" refers 821 to a key establishment algorithm that can be broken in real-time, and 822 an authentication scheme that can be broken off-line, respectively. 823 See [KHLC07] for more details. The requirements in this document 824 disapprove the use of key establishment algorithms that can be broken 825 on-line. 827 Mutually anonymous tunnel protocols are prone to man-in-the-middle 828 attacks described in [KHLC07]. During such an attack, an adversary 829 establishes a tunnel with each the peer and the authentication 830 server, while peer and server believe that they established a tunnel 831 with each other. Once both tunnels have been established, the 832 adversary can eavesdrop on all communications within the tunnels, 833 i.e. the execution of the inner authentication method(s). 834 Consequently, the adversary can eavesdrop on the identifiers that are 835 exchanged as part of the EAP method and thus, the privacy of peer 836 and/or authentication server is compromised along with any other data 837 transmitted within the tunnels. This document requires server 838 authentication to avoid the risks associated with anonymous cipher 839 suites. 841 6.2. Tunneled Authentication 843 In many cases a tunnel method provides mutual authentication by 844 authenticating the server during tunnel establishment and 845 authenticating the peer within the tunnel using an EAP method. As 846 described in [TUNNEL-MITM], this mode of operation can allow tunnel 847 man-in-the-middle attackers to authenticate to the server as the peer 848 by tunneling the inner EAP protocol messages to and from a peer 849 executing the method outside a tunnel or with an untrustworthy 850 server. Cryptographic binding between the established keying 851 material from the inner authentication method(s) and the tunnel 852 protocol verifies that the endpoints of the tunnel and the inner 853 authentication method(s) are the same. This can thwart the attack if 854 the inner method derived keys of sufficient strength that they cannot 855 be broken in real-time. 857 In cases where the inner authentication method does not generate any 858 or only weak key material, security policies must be enforced such 859 that the peer cannot execute the inner method with the same 860 credentials outside a protective tunnel or with an untrustworthy 861 server. 863 6.3. Data External to Tunnel 865 The tunnel method will use data that is outside the TLS tunnel such 866 as the EAP type code or version numbers. If an attacker can 867 compromise the protocol by modifying these values the tunnel method 868 MUST protect this data from modification. In some cases external 869 data may not need additional protection because it is implicitly 870 verified during the protocol operation. 872 6.4. Separation of TLS Tunnel and Inner Authentication Termination 874 Terminating the inner method at a different location than the outer 875 tunnel needs careful consideration. The inner method data may be 876 vulnerable to modification and eavesdropping between the server that 877 terminates the tunnel and the server that terminates the inner 878 method. For example if a clear text password is used then it may be 879 sent to the inner method server in a RADIUS password attribute which 880 uses weak encryption that may not be suitable protection for many 881 environments. 883 In some cases terminating the tunnel at a different location may make 884 it difficult for a peer to authenticate the server and trust it for 885 further communication. For example, if the TLS tunnel is terminated 886 by a different organization the peer needs to be able to authenticate 887 and authorize the tunnel server to handle secret credentials that it 888 shares with the home server that terminates the inner method. This 889 may not meet the security policy of many environments. 891 7. References 893 7.1. Normative References 895 [I-D.clancy-emu-chbind] 896 Clancy, C. and K. Hoeper, "Channel Binding Support for EAP 897 Methods", draft-clancy-emu-chbind-04 (work in progress), 898 November 2008. 900 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 901 Adams, "X.509 Internet Public Key Infrastructure Online 902 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 904 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 905 10646", STD 63, RFC 3629, November 2003. 907 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 908 Levkowetz, "Extensible Authentication Protocol (EAP)", 909 RFC 3748, June 2004. 911 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 912 Authentication Protocol (EAP) Method Requirements for 913 Wireless LANs", RFC 4017, March 2005. 915 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 916 Authorization, and Accounting (AAA) Key Management", 917 BCP 132, RFC 4962, July 2007. 919 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 920 Polk, "Server-Based Certificate Validation Protocol 921 (SCVP)", RFC 5055, December 2007. 923 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 924 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 926 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 927 Authentication Protocol (EAP) Key Management Framework", 928 RFC 5247, August 2008. 930 7.2. Informative References 932 [I-D.ietf-nea-pb-tnc] 933 Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture 934 Broker Protocol (PB) Compatible with TNC", 935 draft-ietf-nea-pb-tnc-06 (work in progress), October 2009. 937 [I-D.mahy-eap-enrollment] 938 Mahy, R., "An Extensible Authentication Protocol (EAP) 939 Enrollment Method", draft-mahy-eap-enrollment-01 (work in 940 progress), March 2006. 942 [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 943 ICST QShine , August 2007. 945 [NIST SP 800-108] 946 Chen, L., "Recommendation for Key Derivation Using 947 Pseudorandom Functions", Draft NIST Special 948 Publication 800-108, April 2008. 950 [NIST SP 800-120] 951 Hoeper, K. and L. Chen, "Recommendation for EAP Methods 952 Used in Wireless Network Access Authentication", NIST 953 Special Publication 800-120, September 2009. 955 [NIST SP 800-57] 956 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 957 "Recommendation for Key Management - Part 1: General 958 (Revised)", NIST Special Publication 800-57, part 1, 959 March 2007. 961 [NIST SP 800-57p3] 962 Barker, E., Burr, W., Jones, A., Polk, W., , S., and M. 963 Smid, "Recommendation for Key Management, Part 3 964 Application-Specific Key Management Guidance", Draft NIST 965 Special Publication 800-57,part 3, October 2008. 967 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 968 Authentication Protocol (PEAP) Specification", 969 August 2009. 971 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 972 and Passwords", RFC 4013, February 2005. 974 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 975 Network Access Identifier", RFC 4282, December 2005. 977 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 978 Languages", RFC 4646, September 2006. 980 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 981 Flexible Authentication via Secure Tunneling Extensible 982 Authentication Protocol Method (EAP-FAST)", RFC 4851, 983 May 2007. 985 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 986 "Transport Layer Security (TLS) Session Resumption without 987 Server-Side State", RFC 5077, January 2008. 989 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 990 Interchange", RFC 5198, March 2008. 992 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 993 Tardo, "Network Endpoint Assessment (NEA): Overview and 994 Requirements", RFC 5209, June 2008. 996 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 997 Protocol Tunneled Transport Layer Security Authenticated 998 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 1000 [TUNNEL-MITM] 1001 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1002 in Tunnelled Authentication Protocols", Cryptology ePrint 1003 Archive: Report 2002/163, November 2002. 1005 Appendix A. Changes from -01 1006 o Added combined mutual authentication in section 3.1 1007 o Changed reference from SP 800-52 to SP 800-57,part 3 1008 o In section 6.2 changed terminology to tunnel MitM and security 1009 policy enforcement 1010 o Reworded text in section 3.2 to clarify MITM protection 1011 o Added more specific text about derivation of the CTK 1012 o Removed resource constrained section 1013 o Added support for Non EAP authentication as a use for 1014 extensibility 1015 o Added text to emergency services section to emphasize that 1016 sensitive information should not be sent if the server is 1017 unauthenticated. 1018 o Reworded TLS requirements 1019 o Reworded external data protection requirements 1020 o Added text to section 4.6 that states method must not be re- 1021 defined inside the tunnel. 1022 o Editorial fixes 1024 Appendix B. Changes from -02 1025 o Editorial Fixes 1026 o Clarified client authentication during tunnel establishment 1027 o Changed text so that the tunnel method MUST meet all MUST and 1028 SHOULD requirements relevant to EAP methods in RFCs 4962 and 5247 1030 Appendix C. changes from -03 1031 o Resolution of open issues: 1032 http://trac.tools.ietf.org/wg/emu/trac/report/9 1033 o Revised section 2 to match other similar RFC(Issue 6) 1034 o Cleaned up section 3.2 (issue 8) 1035 o Clarified identity protection scope in section 3.4 and 1036 4.2.1.4(issue 9) 1037 o Changed Emergency Services to anonymous authentication(section 1038 3.5)(issue 10) 1039 o Clarified section 4.1.1 (issue 15) 1040 o Cleaned up TLS requirements in section 4.2.1(issue 11) 1041 o Replaced text in 4.2.1.1.3 with suitable reference 1042 o Improved wording in 4.2.3 and 6.3 (issue 13) 1043 o Update internationalization requirements in 4.3.6 and 4.5.2 1044 (Issues 25,18) 1045 o Updated text in 4.5.1 (issue 16) 1046 o Changed meta-data to SHOULD in 4.5.3 and 4.6.5(Issue 20) 1047 o Changed chained methods to SHOULD in 4.6.2(issue 19) 1048 o Added security consideration for inner method termination(issue 1049 24) 1051 o Updated references 1052 o Editorial changes(issues 7,22,17) 1054 Authors' Addresses 1056 Katrin Hoeper 1057 Motorola, Inc. 1058 1301 E Algonquin Rd 1059 Schaumburg, IL 60196 1060 USA 1062 Email: khoeper@motorola.com 1064 Stephen Hanna 1065 Juniper Networks 1066 3 Beverly Road 1067 Bedford, MA 01730 1068 USA 1070 Email: shanna@juniper.net 1072 Hao Zhou 1073 Cisco Systems, Inc. 1074 4125 Highlander Parkway 1075 Richfield, OH 44286 1076 USA 1078 Email: hzhou@cisco.com 1080 Joseph Salowey (editor) 1081 Cisco Systems, Inc. 1082 2901 3rd. Ave 1083 Seattle, WA 98121 1084 USA 1086 Email: jsalowey@cisco.com