idnits 2.17.1 draft-ietf-emu-eaptunnel-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1028. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1034. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2008) is 5784 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-clancy-emu-chbind-00 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) == Outdated reference: A later version (-06) exists of draft-ietf-nea-pb-tnc-00 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group K. Hoeper 3 Internet-Draft NIST 4 Intended status: Informational S. Hanna 5 Expires: December 27, 2008 Juniper Networks 6 H. Zhou 7 J. Salowey, Ed. 8 Cisco Systems, Inc. 9 June 25, 2008 11 Requirements for an Tunnel Based EAP Method 12 draft-ietf-emu-eaptunnel-req-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 27, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This memo defines the requirements for a tunnel-based Extensible 46 Authentication Protocol (EAP) Method. This method will use Transport 47 Layer Security (TLS) to establish a secure tunnel. The tunnel will 48 provide support for password authentication, EAP authentication and 49 the transport of additional data for other purposes. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 57 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Password Authentication . . . . . . . . . . . . . . . . . 5 59 3.2. Protect Weak EAP Methods . . . . . . . . . . . . . . . . . 5 60 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 5 61 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6 62 3.5. Emergency Services Authentication . . . . . . . . . . . . 6 63 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 6 64 3.7. Credential Provisioning and Enrollment . . . . . . . . . . 7 65 3.8. Resource Constrained Environments . . . . . . . . . . . . 7 66 3.9. Client Authentication During Tunnel Establishment . . . . 7 67 3.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 8 71 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 8 72 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 8 73 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 9 74 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 9 75 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 9 76 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 9 77 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10 78 4.2.1.1.3. Tunnel Authentication and Key Establishment . 10 79 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 80 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 81 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 82 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 83 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 84 4.2.3. EAP Header Protection . . . . . . . . . . . . . . . . 12 85 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 86 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 87 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 88 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13 89 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 90 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 91 4.3.6. Internationalization of Display Strings . . . . . . . 14 92 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 93 4.5. Requirements Associated with Carrying Username and 94 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 95 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 96 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15 97 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 98 4.5.1.3. Server Credential Revocation Checking . . . . . . 15 99 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 100 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 101 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15 102 4.6. Requirements Associated with Carrying EAP Methods . . . . 16 103 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 104 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 105 4.6.3. Cryptographic Binding with TLS Tunnel . . . . . . . . 16 106 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 107 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17 109 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 112 6.1. Ciphersuite Selection . . . . . . . . . . . . . . . . . . 18 113 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 114 6.3. Outer EAP Method Header . . . . . . . . . . . . . . . . . 19 116 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 118 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 121 Intellectual Property and Copyright Statements . . . . . . . . . . 23 123 1. Introduction 125 Running EAP methods within a TLS protected tunnel has been deployed 126 in several different solutions. EAP methods supporting this include 127 PEAP, TTLS [I-D.funk-eap-ttls-v0] and EAP-FAST [RFC4851]. There have 128 been various reasons for employing a protected tunnel for EAP 129 processes. They include protecting weak authentication exchanges, 130 such as username and password. In addition a protected tunnel can 131 provide a means to provide peer identity protection and EAP method 132 chaining. Finally, systems have found it useful to transport 133 additional types of data within the protected tunnel. 135 This document describes the requirements for an EAP tunnel method as 136 well as for a password protocol supporting legacy password databases 137 within the tunnel method. 139 2. Conventions Used In This Document 141 Because this specification is an informational specification (not 142 able to directly use [RFC2119]), the following capitalized words are 143 used to express requirements language used in this specification. 144 Use of each capitalized word within a sentence or phrase carries the 145 following meaning during the EMU WG's method selection process: 147 MUST - indicates an absolute requirement 149 MUST NOT - indicates something absolutely prohibited 151 SHOULD - indicates a strong recommendation of a desired result 153 SHOULD NOT - indicates a strong recommendation against a result 155 MAY - indicates a willingness to allow an optional outcome 157 Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 158 "MAY" carry their normal meaning and are not subject to these 159 definitions. 161 3. Use Cases 163 To motivate and explain the requirements in this document, a 164 representative set of use cases for the EAP tunnel method are 165 supplied here. The candidate tunnel method is expected to meet all 166 of the use cases marked as MUST. 168 3.1. Password Authentication 170 Many legacy systems only support user authentication with passwords. 171 Some of these systems require transport of the actual username and 172 password to the authentication server. This is true for systems 173 where the authentication server does not have access to the cleartext 174 password or a consistent transform of the cleartext password. 175 Example of such systems are one time password (OTP) systems and other 176 systems where the username and password are submitted to an external 177 party for validation. The tunnel method MUST meet this use case. 178 However, it MUST NOT expose the username and password to untrusted 179 parties and it MUST provide protection against man-in-the-middle and 180 dictionary attacks. 182 Since EAP authentication occurs before network access is granted the 183 tunnel method SHOULD provide support for minimal password management 184 tasks including password change, "new PIN mode", and "next token 185 mode" required by some systems. 187 3.2. Protect Weak EAP Methods 189 Some existing EAP methods have vulnerabilities that could be 190 eliminated or reduced by running them inside a protected tunnel. For 191 example, a method such as EAP-MD5 does not provide mutual 192 authentication or protection from dictionary attacks. In addition, 193 tunneled EAP methods are subject to a specific form of man-in-the- 194 middle attack described in [TUNNEL-MITM]. 196 The tunnel method MUST support protection of weak inner methods and 197 protect against man-in-the-middle attacks associated with tunneled 198 authentication. 200 3.3. Chained EAP Methods 202 Several circumstances are best addressed by using chained EAP 203 methods. For example, it may be desirable to authenticate the user 204 and also authenticate the device that he or she is using. However, 205 chained EAP methods from different conversations can be re-directed 206 into the same conversation by an attacker giving the authenticator 207 the impression that both conversations terminate at the same end- 208 point. Cryptographic binding can be used to bind the results of key 209 generating methods together or to an encompassing tunnel. 211 The tunnel method MUST support chained EAP methods while including 212 strong protection against attacks on the method chaining. 214 3.4. Identity Protection 216 When performing an EAP authentication, the peer may want to protect 217 its identity, only disclosing its identity to a trusted backend 218 authentication server. This helps to maintain the privacy of the 219 peer's identity. 221 The tunnel method MUST support identity protection, ensuring that 222 peer identity is not disclosed to the authenticator and any other 223 intermediaries before the server that terminates the tunnel method. 224 If an inner method also provides identity protection, this protection 225 MUST extend all the way to the server that terminates that inner 226 method. Note that the peer may need to expose the realm portion of 227 the EAP outer identity in the NAI [RFC4282] in a roaming scenario in 228 order to reach the appropriate authentication server. 230 3.5. Emergency Services Authentication 232 When wireless VOIP service is provided, some regulations require any 233 user to be able to gain access to the network to make an emergency 234 telephone call. To avoid eavesdropping on this call, it's best to 235 negotiate link layer security as with any other authentication. 237 Therefore, the tunnel method SHOULD allow anonymous peers or server- 238 only authentication, but still derive keys that can be used for link 239 layer security. The tunnel method MAY also allow for the bypass of 240 server authentication processing on the client. Forgoing 241 authentication increases the chance of man-in-the-middle and other 242 types of attacks that can compromise the derived keys used for link 243 layer security. 245 3.6. Network Endpoint Assessment 247 The Network Endpoint Assessment (NEA) protocols and reference model 248 described in [I-D.ietf-nea-requirements] provide a standard way to 249 check the health ("posture") of a device at or after the time it 250 connects to a network. If the device does not comply with the 251 network's requirements, it can be denied access to the network or 252 granted limited access to remediate itself. EAP is a convenient 253 place for conducting an NEA exchange. 255 The tunnel method SHOULD support carrying NEA protocols such as PB- 256 TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel 257 method, these protocols may be required to be carried in an EAP 258 method. 260 3.7. Credential Provisioning and Enrollment 262 When a peer has authenticated with EAP, this is a convenient time to 263 distribute credentials to that peer that may be used for later 264 authentication exchanges. For example, the authentication server can 265 provide a private key or shared key to the peer that can be used by 266 the peer to perform rapid re-authentication or roaming. In addition 267 there have been proposals to perform enrollment within EAP, such as 268 [I-D.mahy-eap-enrollment]. 270 The tunnel method SHOULD support carrying credential distribution 271 protocols. 273 3.8. Resource Constrained Environments 275 A growing number of "resource constrained" devices (e.g. printers and 276 phones) are connecting to IP networks and those networks increasingly 277 require EAP authentication to gain access. Therefore, it is natural 278 to expect that new EAP methods be designed to work as well as 279 possible with these devices. 281 For the purposes of this document, the phrase "resource constrained" 282 means any combination of the following constraints: little processing 283 power, small amounts of memory (both ROM and RAM), small amounts of 284 long-term mutable storage (e.g. flash or hard drive) or none at all, 285 and constrained power usage (perhaps due to small battery). 287 The tunnel method SHOULD be designed so it can be configured to work 288 with "resource constrained" devices, when possible. 290 3.9. Client Authentication During Tunnel Establishment 292 In cases where client authentication can be performed as part of the 293 tunnel establishment it is efficient for the tunnel method to allow 294 this. The tunnel MUST be capable of providing client side 295 authentication during tunnel establishment. 297 3.10. Extensibility 299 The tunnel method MUST provide extensibility so that additional types 300 of data can be carried inside the tunnel in the future. This removes 301 the need to develop new tunneling methods for specific purposes. 303 4. Requirements 304 4.1. General Requirements 306 4.1.1. RFC Compliance 308 The tunnel method MUST include a Security Claims section with all 309 security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In 310 addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 311 3748 that tunnel methods MUST support protection against man-in-the- 312 middle attacks. Furthermore, all tunnel methods MUST support 313 identity protection as specified in Section 7.3 in RFC 3748. 315 The tunnel method MUST be unconditionally compliant with RFC 4017 316 [RFC4017] (using the definition of "unconditionally compliant" 317 contained in section 1.1 of RFC 4017). This means that the method 318 MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT 319 requirements in RFC 4017. 321 The tunnel method MUST meet all the EAP method requirements contained 322 in the EAP Key Management Framework draft [I-D.ietf-eap-keying] or 323 its successor. The tunnel method MUST include MSK and EMSK 324 generation. This will enable the tunnel method to properly fit into 325 the EAP key management framework, maintaining all of the security 326 properties and guarantees of that framework. 328 The tunnel method MUST NOT be tied to any single cryptographic 329 algorithm. Instead, it MUST support run-time negotiation to select 330 among an extensible set of cryptographic algorithms. This 331 "cryptographic algorithm agility" provides several advantages. Most 332 important, when a weakness in an algorithm is discovered or increased 333 processing power overtakes an algorithm, users can easily transition 334 to a new algorithm. Also, users can choose the algorithm that best 335 meets their needs. 337 The tunnel method MUST meet requirements pertinent to EAP method 338 contained in Section 3 of RFC 4962 [RFC4962]. This includes: 339 cryptographic algorithm independence; strong, fresh session keys; 340 replay detection; keying material confidentiality and integrity; 341 confirm cipher suite selection; and uniquely named keys. In 342 addition, the tunnel method MUST support EAP channel bindings to 343 enable a system based on EAP to meet the additional requirements in 344 Section 3 of RFC 4962. 346 4.1.2. Draw from Existing Work 348 Several existing tunnel methods are already in widespread usage: EAP- 349 FAST [RFC4851], EAP-TTLS [I-D.funk-eap-ttls-v0], and PEAP. 350 Considerable experience has been gained from various deployments with 351 these methods. This experience SHOULD be considered when evaluating 352 tunnel methods. If one of these existing tunnel methods can meet the 353 requirements contained in this specification then that method SHOULD 354 be preferred over a new method. 356 Even if minor modifications or extensions to an existing tunnel 357 method are needed, this method SHOULD be preferred over a completely 358 new method so that the advantage of accumulated deployment experience 359 and security analysis can be gained. 361 4.2. Tunnel Requirements 363 Existing tunnel methods make use of TLS [I-D.ietf-tls-rfc4346-bis] to 364 provide the protected tunnel. In general this has worked well so 365 there is consensus to continue to use TLS as the basis for a tunnel 366 method. 368 4.2.1. TLS Requirements 370 The tunnel based method MUST support TLS version 1.2 371 [I-D.ietf-tls-rfc4346-bis] and SHOULD support TLS version 1.0 372 [RFC2246] and version 1.1 [RFC4346] to enable the possibility of 373 backwards compatibility with existing deployments. The following 374 section discusses requirements for TLS Tunnel Establishment. 376 4.2.1.1. Cipher Suites 378 4.2.1.1.1. Cipher Suite Negotiation 380 Cipher suite negotiations always suffer from downgrading attacks when 381 they are not secured by any kind of integrity protection. A common 382 practice is a post integrity check in which, as soon as available, 383 the established keys (here the tunnel key) are used to derive 384 integrity keys. These integrity keys are then used by peer and 385 authentication server to verify whether the cipher suite negotiation 386 has been maliciously altered by another party. 388 Integrity checks prevent downgrading attacks only if the derived 389 integrity keys and the employed integrity algorithms cannot be broken 390 in real-time. See Section 6.1 or [KHLC07] for more information on 391 this. Hence, the tunnel method MUST provide integrity protected 392 cipher suite negotiation with secure integrity algorithms and 393 integrity keys. 395 All versions of TLS meet these requirements as long as the cipher 396 suites used provide strong authentication, key establishment and data 397 integrity protection. 399 4.2.1.1.2. Tunnel Data Protection Algorithms 401 In order to prevent attacks on the cryptographic algorithms employed 402 by inner authentication methods, a tunnel protocol's protection needs 403 to provide a basic level of algorithm strength. The tunnel method 404 MUST provide at least one mandatory to implement cipher suite that 405 provides the equivalent security of 128-bit AES for encryption and 406 message authentication. See [NIST SP 800-57] for a discussion of the 407 relative strengths of common algorithms. 409 4.2.1.1.3. Tunnel Authentication and Key Establishment 411 A tunnel method MUST provide unidirectional authentication from 412 authentication server to EAP peer or mutual authentication between 413 authentication server and EAP peer. The tunnel method MUST provide 414 at least one mandatory to implement cipher suite that provides 415 certificate based authentication of the server and provides optional 416 certificate based authentication of the client. Other types of 417 authentication MAY be supported. 419 At least one mandatory to implement cipher suite MUST meet the 420 following requirements for secure key establishment along with the 421 previous requirements for authentication and data protection 422 algorithms: 424 o One-way key derivation, i.e., a compromised key leads to the 425 compromise of all descendant keys but does not affect the security 426 of any precedent key in the same branch of the key hierarchy. 428 o Cryptographically separated keys, i.e., a compromised key in one 429 branch of the key hierarchy does not affect the security of keys 430 in other branches. 432 o Cryptographically separated entities, i.e., keys held by different 433 entities are cryptographically separate. As a result, the 434 compromise of a single peer does not compromise keying material 435 held by any other peer within the system, including session keys 436 and long-term keys. 438 o Identity binding, i.e., each derived key is bound to the EAP peer 439 and authentication server by including their identifiers as input 440 to the key derivation. 442 o Context binding, i.e., each derived key is bound to its context by 443 including appropriate key labels in the input of the key 444 derivation. 446 o Key lifetime, i.e., each key has a lifetime assigned that does not 447 exceed the lifetime of any key higher in the key hierarchy. 449 o Mutual implicit key authentication, i.e., the keying material 450 derived upon a successful key establishment execution is only 451 known to the EAP peer and authentication server and is kept 452 confidential. 454 o Key freshness, i.e. EAP peer and EAP server are assured that the 455 derived keys are fresh and the re-use of expired key material is 456 prevented. The freshness property is typically achieved by using 457 one or more of the following techniques: nonces, sequence numbers, 458 timestamps. 460 The mandatory to implement cipher suites MUST NOT include "export 461 strength" cipher suites, cipher suites providing mutually anonymous 462 authentication or static Diffie-Hellman cipher suites. NIST 463 publication [NIST SP 800-52] can be consulted for a list of 464 acceptable TLS v1.0 cipher suites and [NIST SP 800-108] for 465 additional information on secure key derivation. 467 In addition a tunnel method SHOULD provide cipher suites to meet the 468 following additional recommendations for good key establishment 469 algorithms: 471 o Key control , i.e., EAP peer and authentication server each 472 contribute to the key computation of the tunnel key. This 473 property prevents that a single protocol participant controls the 474 value of an established key. In that way, protocol participants 475 can ensure that generated keys are fresh and have good random 476 properties. 478 o Key confirmation, i.e., one protocol participant is assured that 479 another participant actually possesses a particular secret key. 480 In the case of mutual key confirmation both the EAP peer and the 481 authentication server are assured that they possess the same key. 482 Key confirmation is commonly achieved by using one of the derived 483 keys to generate a message authentication code. Mutual key 484 confirmation combined with mutual implicit key authentication 485 leads to mutual explicit key authentication. 487 o Forward secrecy (FS), i.e., if a long-term secret key is 488 compromised, it does not compromise keys that have been 489 established in previous EAP executions. This property is 490 typically achieved by executing an ephemeral Diffie-Hellman key 491 establishment. 493 4.2.1.2. Tunnel Replay Protection 495 In order to prevent replay attacks on a tunnel protocol, the message 496 authentication MUST be generated using a time-variant input such as 497 timestamps, sequence numbers, nonces, or a combination of these so 498 that any re-use of the authentication data can be detected as 499 invalid. TLS makes use of an 8 byte sequence number to protect 500 against replay. 502 4.2.1.3. TLS Extensions 504 In order to meet the requirements in this document TLS extensions MAY 505 be used. For example, TLS extensions may be useful in providing 506 certificate revocation information via the TLS OCSP extension (thus 507 meeting the requirement in Section 4.5.1.3). 509 4.2.1.4. Peer Identity Privacy 511 A tunnel protocol MUST support peer privacy. This requires that the 512 username is not transmitted in the clear and, if applicable, the peer 513 certificate is sent confidentially (i.e. encrypted). 515 4.2.1.5. Session Resumption 517 The tunnel method MUST support TLS session resumption as defined in 518 [I-D.ietf-tls-rfc4346-bis]. The tunnel method MAY support other 519 methods of session resumption such as those defined in [RFC5077]. 521 4.2.2. Fragmentation 523 Tunnel establishment sometimes requires the exchange of information 524 that exceeds what can be carried in a single EAP message. In 525 addition information carried within the tunnel may also exceed this 526 limit. Therefore a tunnel method MUST support fragmentation and 527 reassembly. 529 4.2.3. EAP Header Protection 531 A tunnel method SHOULD provide protection of the outer EAP header 532 information when possible to make sure the outer EAP header is not 533 modified by the intermediaries. 535 4.3. Tunnel Payload Requirements 537 This section describes the payload requirements inside the tunnel. 538 These requirements frequently express features that a candidate 539 protocol must be capable of offering so that a deployer can decide 540 whether to make use of that feature. This section does not state 541 requirements about what features of each protocol must be used during 542 a deployment. 544 4.3.1. Extensible Attribute Types 546 The payload MUST be extensible. Some standard payload attribute 547 types will be defined to meet known requirements listed below, such 548 as password authentication, inner EAP method, vendor specific 549 attributes, and result indication. Additional payload attributes MAY 550 be defined in the future to support additional features and data 551 types. 553 4.3.2. Request/Challenge Response Operation 555 The payload MUST support request and response type of half-duplex 556 operation typical of EAP. Multiple attributes may be sent in a 557 single payload. The payload MAY support carrying on multiple 558 authentications in a single payload packet. 560 4.3.3. Mandatory and Optional Attributes 562 The payload MUST support marking of mandatory and optional 563 attributes, as well as an attribute used for rejecting mandatory 564 attributes. Mandatory attributes are attributes sent by the 565 requester that the responder is expected to understand and MUST 566 respond to. If the responder does not understand or support one of 567 the mandatory attributes in the request, it MUST ignore the rest of 568 the attributes and send a NAK attribute to decline the request. The 569 NAK attribute MUST support inclusion of which mandatory attribute is 570 not supported. The optional attributes are attributes that are not 571 mandatory to support and respond to. If the responder does not 572 understand or support the optional attributes, it can ignore these 573 attributes. 575 4.3.4. Vendor Specific Support 577 The payload MUST support communication of an extensible set of 578 vendor-specific attributes. These attributes will be segmented into 579 uniquely identified vendor specific name spaces. They can be used 580 for experiments or vendor specific features. 582 4.3.5. Result Indication 584 The payload MUST support result indication and its acknowledgement, 585 so both the EAP peer and server will end up with a synchronized 586 state. The result indication is needed after each chained inner 587 authentication method and at the end of the authentication, so 588 separate result indication for intermediate and final result MUST be 589 supported. 591 4.3.6. Internationalization of Display Strings 593 The payload MAY provide a standard attribute format that supports 594 international strings. This attribute format MUST support encoding 595 strings in UTF-8 [RFC3629] format. Any strings sent by the server 596 intended for display to the user MUST be sent in UTF-8 format and 597 SHOULD be able to be marked with language information and adapted to 598 the user's language preference. 600 4.4. EAP Channel Binding Requirements 602 The so-called "lying NAS" problem is a well-documented problem with 603 the current Extensible Authentication Protocol (EAP) architecture 604 [RFC3748] when used with pass-through authenticators. Here, a 605 Network Access Server (NAS), or pass-through authenticator, may 606 authenticate to the backend AAA infrastructure using one set of 607 credentials, while representing contrary information to EAP peers. 609 Such attacks can be prevented by so-called channel bindings 610 [I-D.clancy-emu-chbind], in which key channel binding characteristics 611 are transported from the peer to the server, allowing the server to 612 verify whether the authenticator has advertised valid information to 613 the peer. The server can also respond back with additional 614 information that could be useful for the peer to decide whether or 615 not to continue its session with the serving authenticator. 617 The tunnel method MUST be capable of supporting EAP channel bindings 618 described above. 620 4.5. Requirements Associated with Carrying Username and Passwords 622 This section describes the requirements associated with tunneled 623 password authentication. The password authentication mentioned here 624 refers to user or machine authentication using a legacy password 625 database, such as LDAP, OTP, etc. These legacy user databases 626 typically require the password in its original text form in order to 627 authenticate the peer, hence they require the peer to send the clear 628 text user name and password to the EAP server. 630 4.5.1. Security 632 Due to the fact that the EAP peer needs to send clear text password 633 to the EAP server to authenticate to the legacy user database, the 634 security measures in the following sections MUST be met. 636 4.5.1.1. Confidentiality and Integrity 638 The clear text password exchange MUST be integrity and 639 confidentiality protected. As long as the password exchange occurs 640 inside an authenticated and encrypted tunnel, this requirement is 641 met. 643 4.5.1.2. Authentication of Server 645 The EAP server MUST be authenticated before the peer can send the 646 clear text user name and password to the server. 648 4.5.1.3. Server Credential Revocation Checking 650 In some cases, the EAP peer needs to present its password to the 651 server before it has network access to check the revocation status of 652 the server's credentials. Therefore, the tunnel method MUST support 653 mechanisms to check the revocation status of a credential. The 654 tunnel method SHOULD make use of Online Certificate Status Protocol 655 (OCSP) [RFC2560] or Server-based Certificate Validation Protocol 656 (SCVP) [RFC5055] to obtain the revocation status of the EAP server 657 certificate. 659 4.5.2. Internationalization 661 The password authentication exchange MUST support user names and 662 passwords in international languages. It MUST support encoding of 663 user name and password strings in UTF-8 [RFC3629] format. Any 664 strings sent by the server during the password exchange and intended 665 for display to the user MUST be sent in UTF-8 format and SHOULD be 666 able to be marked with language information and adapted to the user's 667 language preference. 669 4.5.3. Meta-data 671 The password authentication exchange MUST support additional 672 associated meta-data which can be used to indicate whether the 673 authentication is for a user or a machine. This allows the EAP 674 server and peer to request and negotiate authentication specifically 675 for a user or machine. This is useful in the case of multiple inner 676 authentications where the user and machine both need to be 677 authenticated. 679 4.5.4. Password Change 681 The password authentication exchange MUST support password change, as 682 well as other multiple round trips exchanges like new pin mode and 683 next token mode for OTP database. 685 4.6. Requirements Associated with Carrying EAP Methods 687 4.6.1. Method Negotiation 689 The tunnel method MUST support the protected negotiation of the inner 690 EAP method. It MUST NOT allow the inner EAP method negotiation to be 691 downgraded or manipulated by intermediaries. 693 4.6.2. Chained Methods 695 The tunnel method MUST support the chaining of multiple EAP methods. 696 The tunnel method MUST allow for the communication of intermediate 697 result and verification of compound binding between executed inner 698 methods when chained methods are employed. 700 4.6.3. Cryptographic Binding with TLS Tunnel 702 The tunnel method MUST provide a mechanism to bind the tunnel 703 protocol and the inner EAP method. This property is referred to as 704 cryptographic binding. Without such bindings attacks are feasible on 705 tunnel methods [TUNNEL-MITM] and chained methods. 707 Cryptographic bindings are typically achieved by securely mixing the 708 established keying material (say tunnel key TK) from the tunnel 709 protocol with the established keying material (say method key MK) 710 from the inner authentication method(s) in order to derive fresh 711 keying material. If chained EAP methods are executed in the tunnel, 712 all derived inner keys are combined to one method key MK. The keying 713 material derived from mixing tunnel and method keys is also referred 714 to as compound key CTK. In particular, CTK is used to derive MSK, 715 EMSK and other transient keys TEK, such as transient encryption keys 716 and integrity protection keys. The key hierarchy for tunnel methods 717 executions that derive compound keys for the purpose of cryptographic 718 binding is depicted in Figure 1. 720 ----------- 721 | TK | MK | 722 ----------- 723 | | 724 v v 725 -------- 726 | CTK | 727 -------- 728 | 729 v 730 ---------------- 731 | | | 732 v v v 733 ------- ------ ------- 734 | TEK | | MSK | | EMSK | 735 ------- ------- -------- 737 Figure 1: Compound Keys 739 For every key deriving inner EAP method that completes successfully 740 within the tunnel cryptographic binding MUST be performed similar to 741 the following: 743 o compute a compound key CTK using the keying material from tunnel 744 protocol and all tunneled inner authentication method(s) as inputs 746 o use compound key CTK to derive transient keys for use in a 747 cryptographic protocol that verifies the integrity of the tunnel 748 and the inner authentication method. 750 Furthermore, the compound key CTK and all keys derived from it SHOULD 751 be derived in accordance to the guidelines for key derivations and 752 key hierarchies as specified in Section 4.2.1.1.3. In particular, 753 all derived keys MUST have a lifetime assigned that does not exceed 754 the lifetime of any key higher in the key hierarchy, and MUST prevent 755 domino effects. 757 4.6.4. Peer Initiated 759 The tunnel method SHOULD allow for the peer to initiate an inner EAP 760 authentication in order to meet its policy requirements for 761 authenticating the server. 763 4.6.5. Method Meta-data 765 The tunnel method MUST allow for the communication of additional data 766 associated with an EAP method. This can be used to indicate whether 767 the authentication is for a user or a machine. This allows the EAP 768 server and peer to request and negotiate authentication specifically 769 for a user or machine. This is useful in the case of multiple inner 770 EAP authentications where the user and machine both need to be 771 authenticated. 773 5. IANA Considerations 775 This document has no IANA considerations. 777 6. Security Considerations 779 A tunnel method is often deployed to provide mutual authentication 780 between EAP Peer and EAP Server and to generate strong key material 781 for use in protecting lower layer protocols. In addition the tunnel 782 is used to protect the communication of additional data, including 783 peer identity between the EAP Peer and EAP Server from disclosure to 784 or modification by an attacker. These sections cover considerations 785 that affect the ability for a method to achieve these goals. 787 6.1. Ciphersuite Selection 789 TLS supports a wide variety of cipher suites providing a variety of 790 security properties. The selection of strong cipher suites is 791 critical to the security of the tunnel method. Selection of a cipher 792 suite with weak or no authentication, such as an anonymous Diffie- 793 Hellman based cipher suite will greatly increase the risk of system 794 compromise. Since a tunnel method uses the TLS tunnel to transport 795 data, the selection of a ciphersuite with weak data encryption and 796 integrity algorithms will also increase the vulnerability of the 797 method to attacks. 799 A tunnel protocol is prone to downgrading attacks if the tunnel 800 protocol supports any key establishment algorithm that can be broken 801 on-line. In a successful downgrading attack, an adversary breaks the 802 selected "weak" key establishment algorithm and optionally the "weak" 803 authentication algorithm without being detected. Here, "weak" refers 804 to a key establishment algorithm that can be broken in real-time, and 805 an authentication scheme that can be broken off-line, respectively. 806 See [KHLC07] for more details. The requirements in this document 807 disapprove the use of key establishment algorithms that can be broken 808 on-line. 810 Mutually anonymous tunnel protocols are prone to man-in-the-middle 811 attacks described in [KHLC07]. During such an attack, an adversary 812 establishes a tunnel with each the peer and the authentication 813 server, while peer and server believe that they established a tunnel 814 with each other. Once both tunnels have been established, the 815 adversary can eavesdrop on all communications within the tunnels, 816 i.e. the execution of the inner authentication method(s). 817 Consequently, the adversary can eavesdrop on the identifiers that are 818 exchanged as part of the EAP method and thus, the privacy of peer 819 and/or authentication server is compromised along with any other data 820 transmitted within the tunnels. 822 6.2. Tunneled Authentication 824 In many cases a tunnel method provides mutual authentication by 825 authenticating the server during tunnel establishment and 826 authenticating the peer within the tunnel using an EAP method. As 827 described in [TUNNEL-MITM], this mode of operation can allow a man- 828 in-the-middle to authenticate to the server as the peer by tunneling 829 the inner EAP protocol messages to and from a peer executing the 830 method outside a tunnel or with an untrustworthy server. 831 Cryptographic binding between the established keying material from 832 the inner authentication method(s) and the tunnel protocol verifies 833 that the endpoints of the tunnel and the inner authentication 834 method(s) are the same. this can thwart the attack if the inner 835 method derived keys of sufficient strength that they cannot be broken 836 in real-time. 838 In cases where the inner authentication method does not generate any 839 or only weak key material care must be taken to ensure that the peer 840 does not execute the inner method with the same credentials outside a 841 protective tunnel or with an untrustworthy server. 843 6.3. Outer EAP Method Header 845 There are several existing EAP methods which use a similar packet 846 format to EAP-TLS. Often for the initial portions of the exchange 847 the execution of the method is identical except for the method ID. 848 Protection of the outer EAP header helps to avoid vulnerabilities 849 that may arise when an attacker attempts to modify packets to make 850 one EAP message look like one from a different method. 852 7. References 854 7.1. Normative References 856 [I-D.clancy-emu-chbind] 857 Clancy, C. and K. Hoeper, "Channel Binding Support for EAP 858 Methods", draft-clancy-emu-chbind-00 (work in progress), 859 February 2008. 861 [I-D.ietf-eap-keying] 862 Aboba, B., Simon, D., and P. Eronen, "Extensible 863 Authentication Protocol (EAP) Key Management Framework", 864 draft-ietf-eap-keying-22 (work in progress), 865 November 2007. 867 [I-D.ietf-tls-rfc4346-bis] 868 Dierks, T. and E. Rescorla, "The Transport Layer Security 869 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10 870 (work in progress), March 2008. 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, March 1997. 875 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 876 Adams, "X.509 Internet Public Key Infrastructure Online 877 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 879 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 880 10646", STD 63, RFC 3629, November 2003. 882 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 883 Levkowetz, "Extensible Authentication Protocol (EAP)", 884 RFC 3748, June 2004. 886 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 887 Authentication Protocol (EAP) Method Requirements for 888 Wireless LANs", RFC 4017, March 2005. 890 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 891 Authorization, and Accounting (AAA) Key Management", 892 BCP 132, RFC 4962, July 2007. 894 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 895 Polk, "Server-Based Certificate Validation Protocol 896 (SCVP)", RFC 5055, December 2007. 898 7.2. Informative References 900 [I-D.funk-eap-ttls-v0] 901 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 902 Authentication Protocol Version 0 (EAP-TTLSv0)", 903 draft-funk-eap-ttls-v0-05 (work in progress), April 2008. 905 [I-D.ietf-nea-pb-tnc] 906 Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture 907 Broker Protocol (PB) Compatible with TNC", 908 draft-ietf-nea-pb-tnc-00 (work in progress), April 2008. 910 [I-D.ietf-nea-requirements] 911 Sangster, P., "Network Endpoint Assessment (NEA): Overview 912 and Requirements", draft-ietf-nea-requirements-07 (work in 913 progress), April 2008. 915 [I-D.mahy-eap-enrollment] 916 Mahy, R., "An Extensible Authentication Protocol (EAP) 917 Enrollment Method", draft-mahy-eap-enrollment-01 (work in 918 progress), March 2006. 920 [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 921 ICST QShine , August 2007. 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-52] 929 Chernick, C., Edington III, C., Fanto, M., and R. 930 Rosenthal, "Guidelines for the Selection and Use of 931 Transport Layer Security (TLS) Implementations", NIST 932 Special Publication 800-52, June 2005. 934 [NIST SP 800-57] 935 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 936 "Recommendation for Key Management - Part 1: General 937 (Revised)", NIST Special Publication 800-57, March 2007. 939 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 940 RFC 2246, January 1999. 942 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 943 Network Access Identifier", RFC 4282, December 2005. 945 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 946 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 948 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 949 Flexible Authentication via Secure Tunneling Extensible 950 Authentication Protocol Method (EAP-FAST)", RFC 4851, 951 May 2007. 953 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 954 "Transport Layer Security (TLS) Session Resumption without 955 Server-Side State", RFC 5077, January 2008. 957 [TUNNEL-MITM] 958 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 959 in Tunnelled Authentication Protocols", Cryptology ePrint 960 Archive: Report 2002/163, November 2002. 962 Authors' Addresses 964 Katrin Hoeper 965 NIST 966 100 Bureau Drive, MS: 8930 967 Gaithersburg, MD 20899 968 USA 970 Email: khoeper@nist.gov 972 Stephen Hanna 973 Juniper Networks 974 3 Beverly Road 975 Bedford, MA 01730 976 USA 978 Email: shanna@juniper.net 980 Hao Zhou 981 Cisco Systems, Inc. 982 4125 Highlander Parkway 983 Richfield, OH 44286 984 USA 986 Email: hzhou@cisco.com 988 Joseph Salowey (editor) 989 Cisco Systems, Inc. 990 2901 3rd. Ave 991 Seattle, WA 98121 992 USA 994 Email: jsalowey@cisco.com 996 Full Copyright Statement 998 Copyright (C) The IETF Trust (2008). 1000 This document is subject to the rights, licenses and restrictions 1001 contained in BCP 78, and except as set forth therein, the authors 1002 retain all their rights. 1004 This document and the information contained herein are provided on an 1005 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1006 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1007 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1008 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1009 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1010 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1012 Intellectual Property 1014 The IETF takes no position regarding the validity or scope of any 1015 Intellectual Property Rights or other rights that might be claimed to 1016 pertain to the implementation or use of the technology described in 1017 this document or the extent to which any license under such rights 1018 might or might not be available; nor does it represent that it has 1019 made any independent effort to identify any such rights. Information 1020 on the procedures with respect to rights in RFC documents can be 1021 found in BCP 78 and BCP 79. 1023 Copies of IPR disclosures made to the IETF Secretariat and any 1024 assurances of licenses to be made available, or the result of an 1025 attempt made to obtain a general license or permission for the use of 1026 such proprietary rights by implementers or users of this 1027 specification can be obtained from the IETF on-line IPR repository at 1028 http://www.ietf.org/ipr. 1030 The IETF invites any interested party to bring to its attention any 1031 copyrights, patents or patent applications, or other proprietary 1032 rights that may cover technology that may be required to implement 1033 this standard. Please address the information to the IETF at 1034 ietf-ipr@ietf.org. 1036 Acknowledgment 1038 Funding for the RFC Editor function is provided by the IETF 1039 Administrative Support Activity (IASA).