idnits 2.17.1 draft-ietf-emu-eaptunnel-req-01.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 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1009. 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 (October 31, 2008) is 5653 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-03 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-ietf-nea-pb-tnc-01 -- 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: 3 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: May 4, 2009 Juniper Networks 6 H. Zhou 7 J. Salowey, Ed. 8 Cisco Systems, Inc. 9 October 31, 2008 11 Requirements for an Tunnel Based EAP Method 12 draft-ietf-emu-eaptunnel-req-01.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 May 4, 2009. 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. Resource Constrained Environments . . . . . . . . . . . . 6 65 3.8. Client Authentication During Tunnel Establishment . . . . 7 66 3.9. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 68 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 70 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 7 71 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 8 72 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 8 73 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 9 74 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 9 75 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 9 76 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 9 77 4.2.1.1.3. Tunnel Authentication and Key Establishment . 9 78 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11 79 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11 80 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 81 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 82 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 83 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 84 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 85 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12 86 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 87 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13 88 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 89 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 90 4.3.6. Internationalization of Display Strings . . . . . . . 13 91 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 92 4.5. Requirements Associated with Carrying Username and 93 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 94 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 95 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14 96 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14 97 4.5.1.3. Server Credential Revocation Checking . . . . . . 14 98 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 99 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 100 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15 101 4.6. Requirements Associated with Carrying EAP Methods . . . . 15 102 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 15 103 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 15 104 4.6.3. Cryptographic Binding with TLS Tunnel . . . . . . . . 15 105 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 106 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17 108 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 110 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 111 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 17 112 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 18 113 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 116 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 117 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 120 Intellectual Property and Copyright Statements . . . . . . . . . . 23 122 1. Introduction 124 Running EAP methods within a TLS protected tunnel has been deployed 125 in several different solutions. EAP methods supporting this include 126 PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. There have been various 127 reasons for employing a protected tunnel for EAP processes. They 128 include protecting weak authentication exchanges, such as username 129 and password. In addition a protected tunnel can provide means to 130 provide peer identity protection and EAP method chaining. Finally, 131 systems have found it useful to transport additional types of data 132 within the protected tunnel. 134 This document describes the requirements for an EAP tunnel method as 135 well as for a password protocol supporting legacy password 136 verification within the tunnel method. 138 2. Conventions Used In This Document 140 Because this specification is an informational specification (not 141 able to directly use [RFC2119]), the following capitalized words are 142 used to express requirements language used in this specification. 143 Use of each capitalized word within a sentence or phrase carries the 144 following meaning during the EMU WG's method selection process: 146 MUST - indicates an absolute requirement 148 MUST NOT - indicates something absolutely prohibited 150 SHOULD - indicates a strong recommendation of a desired result 152 SHOULD NOT - indicates a strong recommendation against a result 154 MAY - indicates a willingness to allow an optional outcome 156 Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 157 "MAY" carry their normal meaning and are not subject to these 158 definitions. 160 3. Use Cases 162 To motivate and explain the requirements in this document, a 163 representative set of use cases for the EAP tunnel method are 164 supplied here. The candidate tunnel method is expected to meet all 165 of the use cases marked as MUST. 167 3.1. Password Authentication 169 Many legacy systems only support user authentication with passwords. 170 Some of these systems require transport of the actual username and 171 password to the authentication server. This is true for systems 172 where the authentication server does not have access to the cleartext 173 password or a consistent transform of the cleartext password. 174 Example of such systems are one time password (OTP) systems and other 175 systems where the username and password are submitted to an external 176 party for validation. The tunnel method MUST meet this use case. 177 However, it MUST NOT expose the username and password to untrusted 178 parties and it MUST provide protection against man-in-the-middle and 179 dictionary attacks. 181 Since EAP authentication occurs before network access is granted the 182 tunnel method SHOULD enable an inner exchange to provide support for 183 minimal password management tasks including password change, "new PIN 184 mode", and "next token mode" required by some systems. 186 3.2. Protect Weak EAP Methods 188 Some existing EAP methods have vulnerabilities that could be 189 eliminated or reduced by running them inside a protected tunnel. For 190 example, a method such as EAP-MD5 does not provide mutual 191 authentication or protection from dictionary attacks. In addition, 192 tunneled EAP methods are subject to a specific form of man-in-the- 193 middle attack described in [TUNNEL-MITM]. 195 The tunnel method MUST support protection of weak inner methods and 196 protect against man-in-the-middle attacks associated with tunneled 197 authentication. 199 3.3. Chained EAP Methods 201 Several circumstances are best addressed by using chained EAP 202 methods. For example, it may be desirable to authenticate the user 203 and also authenticate the device that he or she is using. However, 204 chained EAP methods from different conversations can be re-directed 205 into the same conversation by an attacker giving the authenticator 206 the impression that both conversations terminate at the same end- 207 point. Cryptographic binding can be used to bind the results of key 208 generating methods together or to an encompassing tunnel. 210 The tunnel method MUST support chained EAP methods while including 211 strong protection against attacks on the method chaining. 213 3.4. Identity Protection 215 When performing an EAP authentication, the peer may want to protect 216 its identity, only disclosing its identity to a trusted backend 217 authentication server. This helps to maintain the privacy of the 218 peer's identity. 220 The tunnel method MUST support identity protection, ensuring that 221 peer identity is not disclosed to the authenticator and any other 222 intermediaries before the server that terminates the tunnel method. 223 Note that the peer may need to expose the realm portion of the EAP 224 outer identity in the NAI [RFC4282] in a roaming scenario in order to 225 reach the appropriate authentication server. 227 3.5. Emergency Services Authentication 229 When wireless VOIP service is provided, some regulations require any 230 user to be able to gain access to the network to make an emergency 231 telephone call. To avoid eavesdropping on this call, it's best to 232 negotiate link layer security as with any other authentication. 234 Therefore, the tunnel method SHOULD allow anonymous peers or server- 235 only authentication, but still derive keys that can be used for link 236 layer security. The tunnel method MAY also allow for the bypass of 237 server authentication processing on the client. Forgoing 238 authentication increases the chance of man-in-the-middle and other 239 types of attacks that can compromise the derived keys used for link 240 layer security. 242 3.6. Network Endpoint Assessment 244 The Network Endpoint Assessment (NEA) protocols and reference model 245 described in [RFC5209] provide a standard way to check the health 246 ("posture") of a device at or after the time it connects to a 247 network. If the device does not comply with the network's 248 requirements, it can be denied access to the network or granted 249 limited access to remediate itself. EAP is a convenient place for 250 conducting an NEA exchange. 252 The tunnel method SHOULD support carrying NEA protocols such as PB- 253 TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel 254 method, these protocols may be required to be carried in an EAP 255 method. 257 3.7. Resource Constrained Environments 259 A growing number of "resource constrained" devices (e.g. printers and 260 phones) are connecting to IP networks and those networks increasingly 261 require EAP authentication to gain access. Therefore, it is natural 262 to expect that new EAP methods be designed to work as well as 263 possible with these devices. 265 For the purposes of this document, the phrase "resource constrained" 266 means any combination of the following constraints: little processing 267 power, small amounts of memory (both ROM and RAM), small amounts of 268 long-term mutable storage (e.g. flash or hard drive) or none at all, 269 and constrained power usage (perhaps due to small battery). 271 The tunnel method SHOULD be designed so it can be configured to work 272 with "resource constrained" devices, when possible. 274 3.8. Client Authentication During Tunnel Establishment 276 In cases where client authentication can be performed as part of the 277 tunnel establishment it is efficient for the tunnel method to allow 278 this. The tunnel MUST be capable of providing client side 279 authentication during tunnel establishment. 281 3.9. Extensibility 283 The tunnel method MUST provide extensibility so that additional types 284 of data can be carried inside the tunnel in the future. This removes 285 the need to develop new tunneling methods for specific purposes. 287 One example of a application for extensibility is credential 288 provisioning. When a peer has authenticated with EAP, this is a 289 convenient time to distribute credentials to that peer that may be 290 used for later authentication exchanges. For example, the 291 authentication server can provide a private key or shared key to the 292 peer that can be used by the peer to perform rapid re-authentication 293 or roaming. In addition there have been proposals to perform 294 enrollment within EAP, such as [I-D.mahy-eap-enrollment]. 296 4. Requirements 298 4.1. General Requirements 300 4.1.1. RFC Compliance 302 The tunnel method MUST include a Security Claims section with all 303 security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In 304 addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 305 3748 that tunnel methods MUST support protection against man-in-the- 306 middle attacks. Furthermore, all tunnel methods MUST support 307 identity protection as specified in Section 7.3 in RFC 3748. 309 The tunnel method MUST be unconditionally compliant with RFC 4017 310 [RFC4017] (using the definition of "unconditionally compliant" 311 contained in section 1.1 of RFC 4017). This means that the method 312 MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT 313 requirements in RFC 4017. 315 The tunnel method MUST meet all the EAP method requirements contained 316 in the EAP Key Management Framework [RFC5247] or its successor. The 317 tunnel method MUST include MSK and EMSK generation. This will enable 318 the tunnel method to properly fit into the EAP key management 319 framework, maintaining all of the security properties and guarantees 320 of that framework. 322 The tunnel method MUST NOT be tied to any single cryptographic 323 algorithm. Instead, it MUST support run-time negotiation to select 324 among an extensible set of cryptographic algorithms. This 325 "cryptographic algorithm agility" provides several advantages. Most 326 important, when a weakness in an algorithm is discovered or increased 327 processing power overtakes an algorithm, users can easily transition 328 to a new algorithm. Also, users can choose the algorithm that best 329 meets their needs. 331 The tunnel method MUST meet requirements pertinent to EAP method 332 contained in Section 3 of RFC 4962 [RFC4962]. This includes: 333 cryptographic algorithm independence; strong, fresh session keys; 334 replay detection; keying material confidentiality and integrity; 335 confirm cipher suite selection; and uniquely named keys. 337 4.1.2. Draw from Existing Work 339 Several existing tunnel methods are already in widespread usage: EAP- 340 FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable 341 experience has been gained from various deployments with these 342 methods. This experience SHOULD be considered when evaluating tunnel 343 methods. If one of these existing tunnel methods can meet the 344 requirements contained in this specification then that method SHOULD 345 be preferred over a new method. 347 Even if minor modifications or extensions to an existing tunnel 348 method are needed, this method SHOULD be preferred over a completely 349 new method so that the advantage of accumulated deployment experience 350 and security analysis can be gained. 352 4.2. Tunnel Requirements 354 Existing tunnel methods make use of TLS [RFC5246] to provide the 355 protected tunnel. In general this has worked well so there is 356 consensus to continue to use TLS as the basis for a tunnel method. 358 4.2.1. TLS Requirements 360 The tunnel based method MUST support TLS version 1.2 [RFC5246] and 361 SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to 362 enable the possibility of backwards compatibility with existing 363 deployments. The following section discusses requirements for TLS 364 Tunnel Establishment. 366 4.2.1.1. Cipher Suites 368 4.2.1.1.1. Cipher Suite Negotiation 370 Cipher suite negotiations always suffer from downgrading attacks when 371 they are not secured by any kind of integrity protection. A common 372 practice is a post integrity check in which, as soon as available, 373 the established keys (here the tunnel key) are used to derive 374 integrity keys. These integrity keys are then used by peer and 375 authentication server to verify whether the cipher suite negotiation 376 has been maliciously altered by another party. 378 Integrity checks prevent downgrading attacks only if the derived 379 integrity keys and the employed integrity algorithms cannot be broken 380 in real-time. See Section 6.1 or [KHLC07] for more information on 381 this. Hence, the tunnel method MUST provide integrity protected 382 cipher suite negotiation with secure integrity algorithms and 383 integrity keys. 385 All versions of TLS meet these requirements as long as the cipher 386 suites used provide strong authentication, key establishment and data 387 integrity protection. 389 4.2.1.1.2. Tunnel Data Protection Algorithms 391 In order to prevent attacks on the cryptographic algorithms employed 392 by inner authentication methods, a tunnel protocol's protection needs 393 to provide a basic level of algorithm strength. The tunnel method 394 MUST provide at least one mandatory to implement cipher suite that 395 provides the equivalent security of 128-bit AES for encryption and 396 message authentication. See [NIST SP 800-57] for a discussion of the 397 relative strengths of common algorithms. 399 4.2.1.1.3. Tunnel Authentication and Key Establishment 401 A tunnel method MUST provide unidirectional authentication from 402 authentication server to EAP peer or mutual authentication between 403 authentication server and EAP peer. The tunnel method MUST provide 404 at least one mandatory to implement cipher suite that provides 405 certificate based authentication of the server and provides optional 406 certificate based authentication of the client. Other types of 407 authentication MAY be supported. 409 At least one mandatory to implement cipher suite MUST meet the 410 following requirements for secure key establishment along with the 411 previous requirements for authentication and data protection 412 algorithms: 414 o One-way key derivation, i.e., a compromised key leads to the 415 compromise of all descendant keys but does not affect the security 416 of any precedent key in the same branch of the key hierarchy. 418 o Cryptographically separated keys, i.e., a compromised key in one 419 branch of the key hierarchy does not affect the security of keys 420 in other branches. 422 o Cryptographically separated entities, i.e., keys held by different 423 entities are cryptographically separate. As a result, the 424 compromise of a single peer does not compromise keying material 425 held by any other peer within the system, including session keys 426 and long-term keys. 428 o Identity binding, i.e., each derived key is bound to the EAP peer 429 and authentication server by including their identifiers as input 430 to the key derivation. 432 o Context binding, i.e., each derived key is bound to its context by 433 including appropriate key labels in the input of the key 434 derivation. 436 o Key lifetime, i.e., each key has a lifetime assigned that does not 437 exceed the lifetime of any key higher in the key hierarchy. 439 o Mutual implicit key authentication, i.e., the keying material 440 derived upon a successful key establishment execution is only 441 known to the EAP peer and authentication server and is kept 442 confidential. 444 o Key freshness, i.e. EAP peer and EAP server are assured that the 445 derived keys are fresh and the re-use of expired key material is 446 prevented. The freshness property is typically achieved by using 447 one or more of the following techniques: nonces, sequence numbers, 448 timestamps. 450 The mandatory to implement cipher suites MUST NOT include "export 451 strength" cipher suites, cipher suites providing mutually anonymous 452 authentication or static Diffie-Hellman cipher suites. NIST 453 publication [NIST SP 800-52] can be consulted for a list of 454 acceptable TLS v1.0 cipher suites and [NIST SP 800-108] for 455 additional information on secure key derivation. 457 In addition a tunnel method SHOULD provide cipher suites to meet the 458 following additional recommendations for good key establishment 459 algorithms: 461 o Key control , i.e., EAP peer and authentication server each 462 contribute to the key computation of the tunnel key. This 463 property prevents that a single protocol participant controls the 464 value of an established key. In that way, protocol participants 465 can ensure that generated keys are fresh and have good random 466 properties. 468 o Key confirmation, i.e., one protocol participant is assured that 469 another participant actually possesses a particular secret key. 470 In the case of mutual key confirmation both the EAP peer and the 471 authentication server are assured that they possess the same key. 472 Key confirmation is commonly achieved by using one of the derived 473 keys to generate a message authentication code. Mutual key 474 confirmation combined with mutual implicit key authentication 475 leads to mutual explicit key authentication. 477 o Forward secrecy (FS), i.e., if a long-term secret key is 478 compromised, it does not compromise keys that have been 479 established in previous EAP executions. This property is 480 typically achieved by executing an ephemeral Diffie-Hellman key 481 establishment. 483 4.2.1.2. Tunnel Replay Protection 485 In order to prevent replay attacks on a tunnel protocol, the message 486 authentication MUST be generated using a time-variant input such as 487 timestamps, sequence numbers, nonces, or a combination of these so 488 that any re-use of the authentication data can be detected as 489 invalid. TLS makes use of an 8 byte sequence number to protect 490 against replay. 492 4.2.1.3. TLS Extensions 494 In order to meet the requirements in this document TLS extensions MAY 495 be used. For example, TLS extensions may be useful in providing 496 certificate revocation information via the TLS OCSP extension (thus 497 meeting the requirement in Section 4.5.1.3). 499 4.2.1.4. Peer Identity Privacy 501 A tunnel protocol MUST support peer privacy. This requires that the 502 username and other attributes associated with the peer are not 503 transmitted in the clear or to an unauthenticated, unauthorized 504 party. If applicable, the peer certificate is sent confidentially 505 (i.e. encrypted). 507 4.2.1.5. Session Resumption 509 The tunnel method MUST support TLS session resumption as defined in 510 [RFC5246]. The tunnel method MAY support other methods of session 511 resumption such as those defined in [RFC5077]. 513 4.2.2. Fragmentation 515 Tunnel establishment sometimes requires the exchange of information 516 that exceeds what can be carried in a single EAP message. In 517 addition information carried within the tunnel may also exceed this 518 limit. Therefore a tunnel method MUST support fragmentation and 519 reassembly. 521 4.2.3. Protection of Data External to Tunnel 523 A tunnel method MUST provide protection of any data external to the 524 TLS tunnel that can cause a problem if it is modified by an attacker. 525 This may include data such as type codes and version numbers 527 4.3. Tunnel Payload Requirements 529 This section describes the payload requirements inside the tunnel. 530 These requirements frequently express features that a candidate 531 protocol must be capable of offering so that a deployer can decide 532 whether to make use of that feature. This section does not state 533 requirements about what features of each protocol must be used during 534 a deployment. 536 4.3.1. Extensible Attribute Types 538 The payload MUST be extensible. Some standard payload attribute 539 types will be defined to meet known requirements listed below, such 540 as password authentication, inner EAP method, vendor specific 541 attributes, and result indication. Additional payload attributes MAY 542 be defined in the future to support additional features and data 543 types. 545 4.3.2. Request/Challenge Response Operation 547 The payload MUST support request and response type of half-duplex 548 operation typical of EAP. Multiple attributes may be sent in a 549 single payload. The payload MAY support carrying on multiple 550 authentications in a single payload packet. 552 4.3.3. Mandatory and Optional Attributes 554 The payload MUST support marking of mandatory and optional 555 attributes, as well as an attribute used for rejecting mandatory 556 attributes. Mandatory attributes are attributes sent by the 557 requester that the responder is expected to understand and MUST 558 respond to. If the responder does not understand or support one of 559 the mandatory attributes in the request, it MUST ignore the rest of 560 the attributes and send a NAK attribute to decline the request. The 561 NAK attribute MUST support inclusion of which mandatory attribute is 562 not supported. The optional attributes are attributes that are not 563 mandatory to support and respond to. If the responder does not 564 understand or support the optional attributes, it can ignore these 565 attributes. 567 4.3.4. Vendor Specific Support 569 The payload MUST support communication of an extensible set of 570 vendor-specific attributes. These attributes will be segmented into 571 uniquely identified vendor specific name spaces. They can be used 572 for experiments or vendor specific features. 574 4.3.5. Result Indication 576 The payload MUST support result indication and its acknowledgement, 577 so both the EAP peer and server will end up with a synchronized 578 state. The result indication is needed after each chained inner 579 authentication method and at the end of the authentication, so 580 separate result indication for intermediate and final result MUST be 581 supported. 583 4.3.6. Internationalization of Display Strings 585 The payload MAY provide a standard attribute format that supports 586 international strings. This attribute format MUST support encoding 587 strings in UTF-8 [RFC3629] format. Any strings sent by the server 588 intended for display to the user MUST be sent in UTF-8 format and 589 SHOULD be able to be marked with language information and adapted to 590 the user's language preference. 592 4.4. EAP Channel Binding Requirements 594 The tunnel method MUST be capable of meeting EAP channel binding 595 requirements described in [I-D.clancy-emu-chbind]. 597 4.5. Requirements Associated with Carrying Username and Passwords 599 This section describes the requirements associated with tunneled 600 password authentication. The password authentication mentioned here 601 refers to user or machine authentication using a legacy password 602 database or verifier, such as LDAP, OTP, etc. These typically 603 require the password in its original text form in order to 604 authenticate the peer, hence they require the peer to send the clear 605 text user name and password to the EAP server. 607 4.5.1. Security 609 Due to the fact that the EAP peer needs to send clear text password 610 to the EAP server to authenticate against the legacy user 611 information, the security measures in the following sections MUST be 612 met. 614 4.5.1.1. Confidentiality and Integrity 616 The clear text password exchange MUST be integrity and 617 confidentiality protected. As long as the password exchange occurs 618 inside an authenticated and encrypted tunnel, this requirement is 619 met. 621 4.5.1.2. Authentication of Server 623 The EAP server MUST be authenticated before the peer can send the 624 clear text password to the server. 626 4.5.1.3. Server Credential Revocation Checking 628 In some cases, the EAP peer needs to present its password to the 629 server before it has network access to check the revocation status of 630 the server's credentials. Therefore, the tunnel method MUST support 631 mechanisms to check the revocation status of a credential. The 632 tunnel method SHOULD make use of Online Certificate Status Protocol 633 (OCSP) [RFC2560] or Server-based Certificate Validation Protocol 634 (SCVP) [RFC5055] to obtain the revocation status of the EAP server 635 certificate. 637 4.5.2. Internationalization 639 The password authentication exchange MUST support user names and 640 passwords in international languages. It MUST support encoding of 641 user name and password strings in UTF-8 [RFC3629] format. Any 642 strings sent by the server during the password exchange and intended 643 for display to the user MUST be sent in UTF-8 format and SHOULD be 644 able to be marked with language information and adapted to the user's 645 language preference. 647 4.5.3. Meta-data 649 The password authentication exchange MUST support additional 650 associated meta-data which can be used to indicate whether the 651 authentication is for a user or a machine. This allows the EAP 652 server and peer to request and negotiate authentication specifically 653 for a user or machine. This is useful in the case of multiple inner 654 authentications where the user and machine both need to be 655 authenticated. 657 4.5.4. Password Change 659 The password authentication exchange MUST support password change, as 660 well as other multiple round trips exchanges like new pin mode and 661 next token mode for OTP verifiers. 663 4.6. Requirements Associated with Carrying EAP Methods 665 The tunnel method MUST be able to carry inner EAP methods without 666 modifying them. 668 4.6.1. Method Negotiation 670 The tunnel method MUST support the protected negotiation of the inner 671 EAP method. It MUST NOT allow the inner EAP method negotiation to be 672 downgraded or manipulated by intermediaries. 674 4.6.2. Chained Methods 676 The tunnel method MUST support the chaining of multiple EAP methods. 677 The tunnel method MUST allow for the communication of intermediate 678 result and verification of compound binding between executed inner 679 methods when chained methods are employed. 681 4.6.3. Cryptographic Binding with TLS Tunnel 683 The tunnel method MUST provide a mechanism to bind the tunnel 684 protocol and the inner EAP method. This property is referred to as 685 cryptographic binding. Without such bindings attacks are feasible on 686 tunnel methods [TUNNEL-MITM] and chained methods. 688 Cryptographic bindings are typically achieved by securely mixing the 689 established keying material (say tunnel key TK) from the tunnel 690 protocol with the established keying material (say method key MK) 691 from the inner authentication method(s) in order to derive fresh 692 keying material. If chained EAP methods are executed in the tunnel, 693 all derived inner keys are combined to one method key MK. The keying 694 material derived from mixing tunnel and method keys is also referred 695 to as compound tunnel key (CTK). In particular, CTK is used to 696 derive the EAP MSK, EMSK and other transient keys (TEK), such as 697 transient encryption keys and integrity protection keys. The key 698 hierarchy for tunnel methods executions that derive compound keys for 699 the purpose of cryptographic binding is depicted in Figure 1. 701 ----------- 702 | TK | MK | 703 ----------- 704 | | 705 v v 706 -------- 707 | CTK | 708 -------- 709 | 710 v 711 ---------------- 712 | | | 713 v v v 714 ------- ------ ------- 715 | TEK | | MSK | | EMSK | 716 ------- ------- -------- 718 Figure 1: Compound Keys 720 For every key deriving inner EAP method that completes successfully 721 within the tunnel cryptographic binding MUST be performed similar to 722 the following: 724 o compute a compound key CTK using the keying material from tunnel 725 protocol and all tunneled inner authentication method(s) as inputs 727 o use compound key CTK to derive transient keys for use in a 728 cryptographic protocol that verifies the integrity of the tunnel 729 and the inner authentication method. 731 Furthermore, the compound key CTK and all keys derived from it SHOULD 732 be derived in accordance to the guidelines for key derivations and 733 key hierarchies as specified in Section 4.2.1.1.3. In particular, 734 all derived keys MUST have a lifetime assigned that does not exceed 735 the lifetime of any key higher in the key hierarchy, and MUST prevent 736 domino effects where a compromise in one part of the system leads to 737 compromises in other parts of the system. 739 4.6.4. Peer Initiated 741 The tunnel method SHOULD allow for the peer to initiate an inner EAP 742 authentication in order to meet its policy requirements for 743 authenticating the server. 745 4.6.5. Method Meta-data 747 The tunnel method MUST allow for the communication of additional data 748 associated with an EAP method. This can be used to indicate whether 749 the authentication is for a user or a machine. This allows the EAP 750 server and peer to request and negotiate authentication specifically 751 for a user or machine. This is useful in the case of multiple inner 752 EAP authentications where the user and machine both need to be 753 authenticated. 755 5. IANA Considerations 757 This document has no IANA considerations. 759 6. Security Considerations 761 A tunnel method is often deployed to provide mutual authentication 762 between EAP Peer and EAP Server and to generate strong key material 763 for use in protecting lower layer protocols. In addition the tunnel 764 is used to protect the communication of additional data, including 765 peer identity between the EAP Peer and EAP Server from disclosure to 766 or modification by an attacker. These sections cover considerations 767 that affect the ability for a method to achieve these goals. 769 6.1. Cipher Suite Selection 771 TLS supports a wide variety of cipher suites providing a variety of 772 security properties. The selection of strong cipher suites is 773 critical to the security of the tunnel method. Selection of a cipher 774 suite with weak or no authentication, such as an anonymous Diffie- 775 Hellman based cipher suite will greatly increase the risk of system 776 compromise. Since a tunnel method uses the TLS tunnel to transport 777 data, the selection of a ciphersuite with weak data encryption and 778 integrity algorithms will also increase the vulnerability of the 779 method to attacks. 781 A tunnel protocol is prone to downgrading attacks if the tunnel 782 protocol supports any key establishment algorithm that can be broken 783 on-line. In a successful downgrading attack, an adversary breaks the 784 selected "weak" key establishment algorithm and optionally the "weak" 785 authentication algorithm without being detected. Here, "weak" refers 786 to a key establishment algorithm that can be broken in real-time, and 787 an authentication scheme that can be broken off-line, respectively. 788 See [KHLC07] for more details. The requirements in this document 789 disapprove the use of key establishment algorithms that can be broken 790 on-line. 792 Mutually anonymous tunnel protocols are prone to man-in-the-middle 793 attacks described in [KHLC07]. During such an attack, an adversary 794 establishes a tunnel with each the peer and the authentication 795 server, while peer and server believe that they established a tunnel 796 with each other. Once both tunnels have been established, the 797 adversary can eavesdrop on all communications within the tunnels, 798 i.e. the execution of the inner authentication method(s). 799 Consequently, the adversary can eavesdrop on the identifiers that are 800 exchanged as part of the EAP method and thus, the privacy of peer 801 and/or authentication server is compromised along with any other data 802 transmitted within the tunnels. This document requires server 803 authentication to avoid the risks associated with anonymous cipher 804 suites. 806 6.2. Tunneled Authentication 808 In many cases a tunnel method provides mutual authentication by 809 authenticating the server during tunnel establishment and 810 authenticating the peer within the tunnel using an EAP method. As 811 described in [TUNNEL-MITM], this mode of operation can allow a man- 812 in-the-middle to authenticate to the server as the peer by tunneling 813 the inner EAP protocol messages to and from a peer executing the 814 method outside a tunnel or with an untrustworthy server. 815 Cryptographic binding between the established keying material from 816 the inner authentication method(s) and the tunnel protocol verifies 817 that the endpoints of the tunnel and the inner authentication 818 method(s) are the same. This can thwart the attack if the inner 819 method derived keys of sufficient strength that they cannot be broken 820 in real-time. 822 In cases where the inner authentication method does not generate any 823 or only weak key material care must be taken to ensure that the peer 824 does not execute the inner method with the same credentials outside a 825 protective tunnel or with an untrustworthy server. 827 6.3. Data External to Tunnel 829 The tunnel method will use data that is outside the TLS tunnel such 830 as the EAP type code or version numbers. If an attacker can 831 compromise the protocol by modifying these values the tunnel method 832 MUST protect this data. 834 7. References 836 7.1. Normative References 838 [I-D.clancy-emu-chbind] 839 Clancy, C. and K. Hoeper, "Channel Binding Support for EAP 840 Methods", draft-clancy-emu-chbind-03 (work in progress), 841 October 2008. 843 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 844 Requirement Levels", BCP 14, RFC 2119, March 1997. 846 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 847 Adams, "X.509 Internet Public Key Infrastructure Online 848 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 850 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 851 10646", STD 63, RFC 3629, November 2003. 853 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 854 Levkowetz, "Extensible Authentication Protocol (EAP)", 855 RFC 3748, June 2004. 857 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 858 Authentication Protocol (EAP) Method Requirements for 859 Wireless LANs", RFC 4017, March 2005. 861 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 862 Authorization, and Accounting (AAA) Key Management", 863 BCP 132, RFC 4962, July 2007. 865 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 866 Polk, "Server-Based Certificate Validation Protocol 867 (SCVP)", RFC 5055, December 2007. 869 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 870 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 872 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 873 Authentication Protocol (EAP) Key Management Framework", 874 RFC 5247, August 2008. 876 7.2. Informative References 878 [I-D.ietf-nea-pb-tnc] 879 Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture 880 Broker Protocol (PB) Compatible with TNC", 881 draft-ietf-nea-pb-tnc-01 (work in progress), July 2008. 883 [I-D.mahy-eap-enrollment] 884 Mahy, R., "An Extensible Authentication Protocol (EAP) 885 Enrollment Method", draft-mahy-eap-enrollment-01 (work in 886 progress), March 2006. 888 [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 889 ICST QShine , August 2007. 891 [NIST SP 800-108] 892 Chen, L., "Recommendation for Key Derivation Using 893 Pseudorandom Functions", Draft NIST Special 894 Publication 800-108, April 2008. 896 [NIST SP 800-52] 897 Chernick, C., Edington III, C., Fanto, M., and R. 898 Rosenthal, "Guidelines for the Selection and Use of 899 Transport Layer Security (TLS) Implementations", NIST 900 Special Publication 800-52, June 2005. 902 [NIST SP 800-57] 903 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 904 "Recommendation for Key Management - Part 1: General 905 (Revised)", NIST Special Publication 800-57, March 2007. 907 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 908 RFC 2246, January 1999. 910 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 911 Network Access Identifier", RFC 4282, December 2005. 913 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 914 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 916 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 917 Flexible Authentication via Secure Tunneling Extensible 918 Authentication Protocol Method (EAP-FAST)", RFC 4851, 919 May 2007. 921 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 922 "Transport Layer Security (TLS) Session Resumption without 923 Server-Side State", RFC 5077, January 2008. 925 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 926 Tardo, "Network Endpoint Assessment (NEA): Overview and 927 Requirements", RFC 5209, June 2008. 929 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 930 Protocol Tunneled Transport Layer Security Authenticated 931 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 933 [TUNNEL-MITM] 934 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 935 in Tunnelled Authentication Protocols", Cryptology ePrint 936 Archive: Report 2002/163, November 2002. 938 Authors' Addresses 940 Katrin Hoeper 941 NIST 942 100 Bureau Drive, MS: 8930 943 Gaithersburg, MD 20899 944 USA 946 Email: khoeper@nist.gov 948 Stephen Hanna 949 Juniper Networks 950 3 Beverly Road 951 Bedford, MA 01730 952 USA 954 Email: shanna@juniper.net 956 Hao Zhou 957 Cisco Systems, Inc. 958 4125 Highlander Parkway 959 Richfield, OH 44286 960 USA 962 Email: hzhou@cisco.com 963 Joseph Salowey (editor) 964 Cisco Systems, Inc. 965 2901 3rd. Ave 966 Seattle, WA 98121 967 USA 969 Email: jsalowey@cisco.com 971 Full Copyright Statement 973 Copyright (C) The IETF Trust (2008). 975 This document is subject to the rights, licenses and restrictions 976 contained in BCP 78, and except as set forth therein, the authors 977 retain all their rights. 979 This document and the information contained herein are provided on an 980 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 981 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 982 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 983 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 984 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 985 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 987 Intellectual Property 989 The IETF takes no position regarding the validity or scope of any 990 Intellectual Property Rights or other rights that might be claimed to 991 pertain to the implementation or use of the technology described in 992 this document or the extent to which any license under such rights 993 might or might not be available; nor does it represent that it has 994 made any independent effort to identify any such rights. Information 995 on the procedures with respect to rights in RFC documents can be 996 found in BCP 78 and BCP 79. 998 Copies of IPR disclosures made to the IETF Secretariat and any 999 assurances of licenses to be made available, or the result of an 1000 attempt made to obtain a general license or permission for the use of 1001 such proprietary rights by implementers or users of this 1002 specification can be obtained from the IETF on-line IPR repository at 1003 http://www.ietf.org/ipr. 1005 The IETF invites any interested party to bring to its attention any 1006 copyrights, patents or patent applications, or other proprietary 1007 rights that may cover technology that may be required to implement 1008 this standard. Please address the information to the IETF at 1009 ietf-ipr@ietf.org. 1011 Acknowledgment 1013 Funding for the RFC Editor function is provided by the IETF 1014 Administrative Support Activity (IASA).