idnits 2.17.1 draft-ietf-emu-eaptunnel-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 27, 2009) is 5537 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-ietf-nea-pb-tnc-02 -- 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 (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group K. Hoeper 3 Internet-Draft Motorola, Inc. 4 Intended status: Informational S. Hanna 5 Expires: August 31, 2009 Juniper Networks 6 H. Zhou 7 J. Salowey, Ed. 8 Cisco Systems, Inc. 9 February 27, 2009 11 Requirements for a Tunnel Based EAP Method 12 draft-ietf-emu-eaptunnel-req-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 31, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This memo defines the requirements for a tunnel-based Extensible 60 Authentication Protocol (EAP) Method. This method will use Transport 61 Layer Security (TLS) to establish a secure tunnel. The tunnel will 62 provide support for password authentication, EAP authentication and 63 the transport of additional data for other purposes. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Conventions Used In This Document . . . . . . . . . . . . . . 5 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 73 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 74 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 75 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 76 3.5. Emergency Services Authentication . . . . . . . . . . . . 7 77 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 78 3.7. Client Authentication During Tunnel Establishment . . . . 8 79 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 81 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 8 83 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 8 84 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9 85 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 86 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 87 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 88 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 89 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10 90 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 91 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 92 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 13 93 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 13 94 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 13 95 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 13 96 4.2.3. Protection of Data External to Tunnel . . . . . . . . 13 97 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13 98 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 14 99 4.3.2. Request/Challenge Response Operation . . . . . . . . . 14 100 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 14 101 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 14 102 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 14 103 4.3.6. Internationalization of Display Strings . . . . . . . 15 104 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 15 105 4.5. Requirements Associated with Carrying Username and 106 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15 107 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 15 108 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15 109 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 110 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 111 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 16 112 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 16 113 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16 114 4.6. Requirements Associated with Carrying EAP Methods . . . . 16 115 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 116 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 117 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 17 118 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 18 119 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 121 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 123 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 124 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 19 125 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 20 126 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20 128 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 129 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 130 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 132 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 136 1. Introduction 138 Running EAP methods within a TLS protected tunnel has been deployed 139 in several different solutions. EAP methods supporting this include 140 PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this has 141 worked well so there is consensus to continue to use TLS as the basis 142 for a tunnel method. There have been various reasons for employing a 143 protected tunnel for EAP processes. They include protecting weak 144 authentication exchanges, such as username and password. In addition 145 a protected tunnel can provide means to provide peer identity 146 protection and EAP method chaining. Finally, systems have found it 147 useful to transport additional types of data within the protected 148 tunnel. 150 This document describes the requirements for an EAP tunnel method as 151 well as for a password protocol supporting legacy password 152 verification within the tunnel method. 154 2. Conventions Used In This Document 156 Because this specification is an informational specification (not 157 able to directly use [RFC2119]), the following capitalized words are 158 used to express requirements language used in this specification. 159 Use of each capitalized word within a sentence or phrase carries the 160 following meaning during the EMU WG's method selection process: 162 MUST - indicates an absolute requirement 164 MUST NOT - indicates something absolutely prohibited 166 SHOULD - indicates a strong recommendation of a desired result 168 SHOULD NOT - indicates a strong recommendation against a result 170 MAY - indicates a willingness to allow an optional outcome 172 Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 173 "MAY" carry their normal meaning and are not subject to these 174 definitions. 176 3. Use Cases 178 To motivate and explain the requirements in this document, a 179 representative set of use cases for the EAP tunnel method are 180 supplied here. The candidate tunnel method is expected to support 181 all of the use cases marked as MUST. 183 3.1. Password Authentication 185 Many legacy systems only support user authentication with passwords. 186 Some of these systems require transport of the actual username and 187 password to the authentication server. This is true for systems 188 where the authentication server does not have access to the cleartext 189 password or a consistent transform of the cleartext password. 190 Example of such systems are one time password (OTP) systems and other 191 systems where the username and password are submitted to an external 192 party for validation. The tunnel method MUST support this use case. 193 However, it MUST NOT expose the username and password to untrusted 194 parties and it MUST provide protection against man-in-the-middle and 195 dictionary attacks. The combination of the tunnel authentication and 196 password authentication MUST enable mutual authentication. 198 Since EAP authentication occurs before network access is granted the 199 tunnel method SHOULD enable an inner exchange to provide support for 200 minimal password management tasks including password change, "new PIN 201 mode", and "next token mode" required by some systems. 203 3.2. Protection of Weak EAP Methods 205 Some existing EAP methods have vulnerabilities that could be 206 eliminated or reduced by running them inside a protected tunnel. For 207 example, a method such as EAP-MD5 does not provide mutual 208 authentication or protection from dictionary attacks. Without extra 209 protection, tunnel-based EAP methods are vulnerable to a special type 210 of man-in-the-middle attacks documented in [TUNNEL-MITM]. This 211 attack is referred to as "tunnel MitM attack" in the remainder of 212 this document. The additional protection needed to thwart tunnel 213 MitM attacks depends on the inner method executed within the tunnel. 214 In particular, when weak methods are used, security policies 215 enforcing that such methods can only be executed inside a tunnel but 216 never outside one are required to mitigate the attack. On the other 217 hand, a technical solution (so-called cryptographic bindings) can be 218 used whenever the inner method is not susceptible to attacks outside 219 a tunnel and derives keying material. Only the latter mitigation 220 technique can be made an actual requirement for tunnel-based EAP 221 methods (see Section 4.6.3), while security policies are outside the 222 scope of this requirement draft. Please refer to [NIST SP 800-120] 223 for a discussion on security policies and complete solutions for 224 thwarting tunnel MitM attacks. 226 The tunnel method MUST support protection of weak EAP methods, 227 including cryptographic protection from tunnel MitM attacks. In 228 combination with an appropriate security policy this will thwart MitM 229 attacks against inner methods. 231 3.3. Chained EAP Methods 233 Several circumstances are best addressed by using chained EAP 234 methods. For example, it may be desirable to authenticate the user 235 and also authenticate the device that he or she is using. However, 236 chained EAP methods from different conversations can be re-directed 237 into the same conversation by an attacker giving the authenticator 238 the impression that both conversations terminate at the same end- 239 point. Cryptographic binding can be used to bind the results of key 240 generating methods together or to an encompassing tunnel. 242 The tunnel method MUST support chained EAP methods while including 243 strong protection against attacks on the method chaining. 245 3.4. Identity Protection 247 When performing an EAP authentication, the peer may want to protect 248 its identity, only disclosing its identity to a trusted backend 249 authentication server. This helps to maintain the privacy of the 250 peer's identity. 252 The tunnel method MUST support identity protection, ensuring that 253 peer identity is not disclosed to the authenticator and any other 254 intermediaries before the server that terminates the tunnel method. 255 Note that the peer may need to expose the realm portion of the EAP 256 outer identity in the NAI [RFC4282] in a roaming scenario in order to 257 reach the appropriate authentication server. 259 3.5. Emergency Services Authentication 261 When wireless VOIP service is provided, some regulations require any 262 user to be able to gain access to the network to make an emergency 263 telephone call. To avoid eavesdropping on this call, it's best to 264 negotiate link layer security as with any other authentication. 266 Therefore, the tunnel method SHOULD allow anonymous peers or server- 267 only authentication, but still derive keys that can be used for link 268 layer security. The tunnel method MAY also allow for the bypass of 269 server authentication processing on the client. Forgoing 270 authentication increases the chance of man-in-the-middle and other 271 types of attacks that can compromise the derived keys used for link 272 layer security. In addition, passwords and other sensitive 273 information must not be disclosed to an unauthenticated or 274 unauthorized server. 276 3.6. Network Endpoint Assessment 278 The Network Endpoint Assessment (NEA) protocols and reference model 279 described in [RFC5209] provide a standard way to check the health 280 ("posture") of a device at or after the time it connects to a 281 network. If the device does not comply with the network's 282 requirements, it can be denied access to the network or granted 283 limited access to remediate itself. EAP is a convenient place for 284 conducting an NEA exchange. 286 The tunnel method SHOULD support carrying NEA protocols such as PB- 287 TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel 288 method, these protocols may be required to be carried in an EAP 289 method. 291 3.7. Client Authentication During Tunnel Establishment 293 In cases where client authentication can be performed as part of the 294 tunnel establishment it is efficient for the tunnel method to allow 295 this. The tunnel method MUST be capable of providing client side 296 authentication during tunnel establishment. 298 3.8. Extensibility 300 The tunnel method MUST provide extensibility so that additional types 301 of data can be carried inside the tunnel in the future. This removes 302 the need to develop new tunneling methods for specific purposes. 304 One example of a application for extensibility is credential 305 provisioning. When a peer has authenticated with EAP, this is a 306 convenient time to distribute credentials to that peer that may be 307 used for later authentication exchanges. For example, the 308 authentication server can provide a private key or shared key to the 309 peer that can be used by the peer to perform rapid re-authentication 310 or roaming. In addition there have been proposals to perform 311 enrollment within EAP, such as [I-D.mahy-eap-enrollment]. Another 312 use for extensibility is support for authentication frameworks other 313 than EAP. 315 4. Requirements 317 4.1. General Requirements 319 4.1.1. RFC Compliance 321 The tunnel method MUST include a Security Claims section with all 322 security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In 323 addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 324 3748 that tunnel methods MUST support protection against man-in-the- 325 middle attacks. Furthermore, all tunnel methods MUST support 326 identity protection as specified in Section 7.3 in RFC 3748. 328 The tunnel method MUST be unconditionally compliant with RFC 4017 329 [RFC4017] (using the definition of "unconditionally compliant" 330 contained in section 1.1 of RFC 4017). This means that the method 331 MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT 332 requirements in RFC 4017. 334 The tunnel method MUST meet all the EAP method requirements contained 335 in the EAP Key Management Framework [RFC5247] or its successor. The 336 tunnel method MUST include MSK and EMSK generation. This will enable 337 the tunnel method to properly fit into the EAP key management 338 framework, maintaining all of the security properties and guarantees 339 of that framework. 341 The tunnel method MUST NOT be tied to any single cryptographic 342 algorithm. Instead, it MUST support run-time negotiation to select 343 among an extensible set of cryptographic algorithms. This 344 "cryptographic algorithm agility" provides several advantages. Most 345 important, when a weakness in an algorithm is discovered or increased 346 processing power overtakes an algorithm, users can easily transition 347 to a new algorithm. Also, users can choose the algorithm that best 348 meets their needs. 350 The tunnel method MUST meet requirements pertinent to EAP method 351 contained in Section 3 of RFC 4962 [RFC4962]. This includes: 352 cryptographic algorithm independence; strong, fresh session keys; 353 replay detection; keying material confidentiality and integrity; 354 confirm cipher suite selection; and uniquely named keys. 356 4.1.2. Draw from Existing Work 358 Several existing tunnel methods are already in widespread usage: EAP- 359 FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable 360 experience has been gained from various deployments with these 361 methods. This experience SHOULD be considered when evaluating tunnel 362 methods. If one of these existing tunnel methods can meet the 363 requirements contained in this specification then that method SHOULD 364 be preferred over a new method. 366 Even if minor modifications or extensions to an existing tunnel 367 method are needed, this method SHOULD be preferred over a completely 368 new method so that the advantage of accumulated deployment experience 369 and security analysis can be gained. 371 4.2. Tunnel Requirements 373 The following section discusses requirements for TLS Tunnel 374 Establishment. 376 4.2.1. TLS Requirements 378 The tunnel based method MUST support TLS version 1.2 [RFC5246] and 379 SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to 380 enable the possibility of backwards compatibility with existing 381 deployments. The following section discusses requirements for TLS 382 Tunnel Establishment. 384 4.2.1.1. Cipher Suites 386 4.2.1.1.1. Cipher Suite Negotiation 388 Cipher suite negotiations always suffer from downgrading attacks when 389 they are not secured by any kind of integrity protection. A common 390 practice is a post integrity check in which, as soon as available, 391 the established keys (here the tunnel key) are used to derive 392 integrity keys. These integrity keys are then used by peer and 393 authentication server to verify whether the cipher suite negotiation 394 has been maliciously altered by another party. 396 Integrity checks prevent downgrading attacks only if the derived 397 integrity keys and the employed integrity algorithms cannot be broken 398 in real-time. See Section 6.1 or [KHLC07] for more information on 399 this. Hence, the tunnel method MUST provide integrity protected 400 cipher suite negotiation with secure integrity algorithms and 401 integrity keys. 403 All versions of TLS meet these requirements as long as the cipher 404 suites used provide strong authentication, key establishment and data 405 integrity protection. 407 4.2.1.1.2. Tunnel Data Protection Algorithms 409 In order to prevent attacks on the cryptographic algorithms employed 410 by inner authentication methods, a tunnel protocol's protection needs 411 to provide a basic level of algorithm strength. The tunnel method 412 MUST provide at least one mandatory to implement cipher suite that 413 provides the equivalent security of 128-bit AES for encryption and 414 message authentication. See [NIST SP 800-57] for a discussion of the 415 relative strengths of common algorithms. 417 4.2.1.1.3. Tunnel Authentication and Key Establishment 419 A tunnel method MUST provide unidirectional authentication from 420 authentication server to EAP peer or mutual authentication between 421 authentication server and EAP peer. The tunnel method MUST provide 422 at least one mandatory to implement cipher suite that provides 423 certificate based authentication of the server and provides optional 424 certificate based authentication of the client. Other types of 425 authentication MAY be supported. 427 At least one mandatory to implement cipher suite MUST meet the 428 following requirements for secure key establishment along with the 429 previous requirements for authentication and data protection 430 algorithms: 432 o One-way key derivation, i.e., a compromised key leads to the 433 compromise of all descendant keys but does not affect the security 434 of any precedent key in the same branch of the key hierarchy. 436 o Cryptographically separated keys, i.e., a compromised key in one 437 branch of the key hierarchy does not affect the security of keys 438 in other branches. 440 o Cryptographically separated entities, i.e., keys held by different 441 entities are cryptographically separate. As a result, the 442 compromise of a single peer does not compromise keying material 443 held by any other peer within the system, including session keys 444 and long-term keys. 446 o Identity binding, i.e., each derived key is bound to the EAP peer 447 and authentication server by including their identifiers as input 448 to the key derivation. 450 o Context binding, i.e., each derived key is bound to its context by 451 including appropriate key labels in the input of the key 452 derivation. 454 o Key lifetime, i.e., each key has a lifetime assigned that does not 455 exceed the lifetime of any key higher in the key hierarchy. 457 o Mutual implicit key authentication, i.e., the keying material 458 derived upon a successful key establishment execution is only 459 known to the EAP peer and authentication server and is kept 460 confidential. 462 o Key freshness, i.e. EAP peer and EAP server are assured that the 463 derived keys are fresh and the re-use of expired key material is 464 prevented. The freshness property is typically achieved by using 465 one or more of the following techniques: nonces, sequence numbers, 466 timestamps. 468 The mandatory to implement cipher suites MUST NOT include "export 469 strength" cipher suites, cipher suites providing mutually anonymous 470 authentication or static Diffie-Hellman cipher suites. NIST 471 publication [NIST SP 800-57p3] can be consulted for a list of 472 acceptable TLS v1.0, v1.1 and v 1.2 cipher suites and NIST 473 publication [NIST SP 800-108] for additional information on secure 474 key derivation. 476 In addition a tunnel method SHOULD provide cipher suites to meet the 477 following additional recommendations for good key establishment 478 algorithms: 480 o Key control , i.e., EAP peer and authentication server each 481 contribute to the key computation of the tunnel key. This 482 property prevents that a single protocol participant controls the 483 value of an established key. In that way, protocol participants 484 can ensure that generated keys are fresh and have good random 485 properties. 487 o Key confirmation, i.e., one protocol participant is assured that 488 another participant actually possesses a particular secret key. 489 In the case of mutual key confirmation both the EAP peer and the 490 authentication server are assured that they possess the same key. 491 Key confirmation is commonly achieved by using one of the derived 492 keys to generate a message authentication code. Mutual key 493 confirmation combined with mutual implicit key authentication 494 leads to mutual explicit key authentication. 496 o Forward secrecy (FS), i.e., if a long-term secret key is 497 compromised, it does not compromise keys that have been 498 established in previous EAP executions. This property is 499 typically achieved by executing an ephemeral Diffie-Hellman key 500 establishment. 502 4.2.1.2. Tunnel Replay Protection 504 In order to prevent replay attacks on a tunnel protocol, the message 505 authentication MUST be generated using a time-variant input such as 506 timestamps, sequence numbers, nonces, or a combination of these so 507 that any re-use of the authentication data can be detected as 508 invalid. TLS makes use of an 8 byte sequence number to protect 509 against replay. 511 4.2.1.3. TLS Extensions 513 In order to meet the requirements in this document TLS extensions MAY 514 be used. For example, TLS extensions may be useful in providing 515 certificate revocation information via the TLS OCSP extension (thus 516 meeting the requirement in Section 4.5.1.3). 518 4.2.1.4. Peer Identity Privacy 520 A tunnel protocol MUST support peer privacy. This requires that the 521 username and other attributes associated with the peer are not 522 transmitted in the clear or to an unauthenticated, unauthorized 523 party. If applicable, the peer certificate is sent confidentially 524 (i.e. encrypted). 526 4.2.1.5. Session Resumption 528 The tunnel method MUST support TLS session resumption as defined in 529 [RFC5246]. The tunnel method MAY support other methods of session 530 resumption such as those defined in [RFC5077]. 532 4.2.2. Fragmentation 534 Tunnel establishment sometimes requires the exchange of information 535 that exceeds what can be carried in a single EAP message. In 536 addition information carried within the tunnel may also exceed this 537 limit. Therefore a tunnel method MUST support fragmentation and 538 reassembly. 540 4.2.3. Protection of Data External to Tunnel 542 An attacker in the middle can modify clear text values such as 543 protocol version and type code information communicated outside the 544 TLS tunnel. If modification of this information can cause 545 vulnerabilities, the tunnel method MUST provide protection against 546 modification of this data. 548 4.3. Tunnel Payload Requirements 550 This section describes the payload requirements inside the tunnel. 551 These requirements frequently express features that a candidate 552 protocol must be capable of offering so that a deployer can decide 553 whether to make use of that feature. This section does not state 554 requirements about what features of each protocol must be used during 555 a deployment. 557 4.3.1. Extensible Attribute Types 559 The payload MUST be extensible. Some standard payload attribute 560 types will be defined to meet known requirements listed below, such 561 as password authentication, inner EAP method, vendor specific 562 attributes, and result indication. Additional payload attributes MAY 563 be defined in the future to support additional features and data 564 types. 566 4.3.2. Request/Challenge Response Operation 568 The payload MUST support request and response type of half-duplex 569 operation typical of EAP. Multiple attributes may be sent in a 570 single payload. The payload MAY support carrying on multiple 571 authentications in a single payload packet. 573 4.3.3. Mandatory and Optional Attributes 575 The payload MUST support marking of mandatory and optional 576 attributes, as well as an attribute used for rejecting mandatory 577 attributes. Mandatory attributes are attributes sent by the 578 requester that the responder is expected to understand and MUST 579 respond to. If the responder does not understand or support one of 580 the mandatory attributes in the request, it MUST ignore the rest of 581 the attributes and send a NAK attribute to decline the request. The 582 NAK attribute MUST support inclusion of which mandatory attribute is 583 not supported. The optional attributes are attributes that are not 584 mandatory to support and respond to. If the responder does not 585 understand or support the optional attributes, it can ignore these 586 attributes. 588 4.3.4. Vendor Specific Support 590 The payload MUST support communication of an extensible set of 591 vendor-specific attributes. These attributes will be segmented into 592 uniquely identified vendor specific name spaces. They can be used 593 for experiments or vendor specific features. 595 4.3.5. Result Indication 597 The payload MUST support result indication and its acknowledgement, 598 so both the EAP peer and server will end up with a synchronized 599 state. The result indication is needed after each chained inner 600 authentication method and at the end of the authentication, so 601 separate result indication for intermediate and final result MUST be 602 supported. 604 4.3.6. Internationalization of Display Strings 606 The payload MAY provide a standard attribute format that supports 607 international strings. This attribute format MUST support encoding 608 strings in UTF-8 [RFC3629] format. Any strings sent by the server 609 intended for display to the user MUST be sent in UTF-8 format and 610 SHOULD be able to be marked with language information and adapted to 611 the user's language preference. 613 4.4. EAP Channel Binding Requirements 615 The tunnel method MUST be capable of meeting EAP channel binding 616 requirements described in [I-D.clancy-emu-chbind]. 618 4.5. Requirements Associated with Carrying Username and Passwords 620 This section describes the requirements associated with tunneled 621 password authentication. The password authentication mentioned here 622 refers to user or machine authentication using a legacy password 623 database or verifier, such as LDAP, OTP, etc. These typically 624 require the password in its original text form in order to 625 authenticate the peer, hence they require the peer to send the clear 626 text user name and password to the EAP server. 628 4.5.1. Security 630 Due to the fact that the EAP peer needs to send clear text password 631 to the EAP server to authenticate against the legacy user 632 information, the security measures in the following sections MUST be 633 met. 635 4.5.1.1. Confidentiality and Integrity 637 The clear text password exchange MUST be integrity and 638 confidentiality protected. As long as the password exchange occurs 639 inside an authenticated and encrypted tunnel, this requirement is 640 met. 642 4.5.1.2. Authentication of Server 644 The EAP server MUST be authenticated before the peer can send the 645 clear text password to the server. 647 4.5.1.3. Server Certificate Revocation Checking 649 In some cases, the EAP peer needs to present its password to the 650 server before it has network access to check the revocation status of 651 the server's credentials. Therefore, the tunnel method MUST support 652 mechanisms to check the revocation status of a credential. The 653 tunnel method SHOULD make use of Online Certificate Status Protocol 654 (OCSP) [RFC2560] or Server-based Certificate Validation Protocol 655 (SCVP) [RFC5055] to obtain the revocation status of the EAP server 656 certificate. 658 4.5.2. Internationalization 660 The password authentication exchange MUST support user names and 661 passwords in international languages. It MUST support encoding of 662 user name and password strings in UTF-8 [RFC3629] format. Any 663 strings sent by the server during the password exchange and intended 664 for display to the user MUST be sent in UTF-8 format and SHOULD be 665 able to be marked with language information and adapted to the user's 666 language preference. 668 4.5.3. Meta-data 670 The password authentication exchange MUST support additional 671 associated meta-data which can be used to indicate whether the 672 authentication is for a user or a machine. This allows the EAP 673 server and peer to request and negotiate authentication specifically 674 for a user or machine. This is useful in the case of multiple inner 675 authentications where the user and machine both need to be 676 authenticated. 678 4.5.4. Password Change 680 The password authentication exchange MUST support password change, as 681 well as other multiple round trips exchanges like new pin mode and 682 next token mode for OTP verifiers. 684 4.6. Requirements Associated with Carrying EAP Methods 686 The tunnel method MUST be able to carry inner EAP methods without 687 modifying them. EAP methods MUST NOT be redefined inside the tunnel. 689 4.6.1. Method Negotiation 691 The tunnel method MUST support the protected negotiation of the inner 692 EAP method. It MUST NOT allow the inner EAP method negotiation to be 693 downgraded or manipulated by intermediaries. 695 4.6.2. Chained Methods 697 The tunnel method MUST support the chaining of multiple EAP methods. 698 The tunnel method MUST allow for the communication of intermediate 699 result and verification of compound binding between executed inner 700 methods when chained methods are employed. 702 4.6.3. Cryptographic Binding with the TLS Tunnel 704 The tunnel method MUST provide a mechanism to bind the tunnel 705 protocol and the inner EAP method. This property is referred to as 706 cryptographic binding. Such bindings are an important tool for 707 mitigating the tunnel MitM attacks on tunnel methods described in 708 [TUNNEL-MITM]. Cryptographic bindings enable the complete prevention 709 of tunnel MitM attacks without the need of additional security 710 policies as long as the inner method derives keys and is not 711 vulnerable to attacks outside a protected tunnel [KHLC07]. Even 712 though weak or non-key deriving inner methods may be permitted, and 713 thus security policies preventing tunnel MitM attacks are still 714 necessary, the tunnel method MUST provide cryptographic bindings, 715 because only this allows migrating to more secure, policy-independent 716 implementations. 718 Cryptographic bindings are typically achieved by securely mixing the 719 established keying material (say tunnel key TK) from the tunnel 720 protocol with the established keying material (say method key MK) 721 from the inner authentication method(s) in order to derive fresh 722 keying material. If chained EAP methods are executed in the tunnel, 723 all derived inner keys are combined with the tunnel key to create a 724 new compound tunnel key (CTK). In particular, CTK is used to derive 725 the EAP MSK, EMSK and other transient keys (TEK), such as transient 726 encryption keys and integrity protection keys. The key hierarchy for 727 tunnel methods executions that derive compound keys for the purpose 728 of cryptographic binding is depicted in Figure 1. 730 In the case of the sequential executions of n inner methods, a 731 chained compound key CTK_i MUST be computed upon the completion of 732 each inner method i such that it contains the compound key of all 733 previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n 734 and CTK_0=TK, where f() is a good key derivation function, such as 735 one that complies with [NIST SP 800-108]. CTK_n SHOULD serve as the 736 key to derive further keys. Figure 1 depicts the key hierarchy in 737 the case of a single inner method. Transient keys derived from the 738 compound key CTK are used in a cryptographic protocol to verify the 739 integrity of the tunnel and the inner authentication method. 741 ----------- 742 | TK | MK | 743 ----------- 744 | | 745 v v 746 -------- 747 | CTK | 748 -------- 749 | 750 v 751 ---------------- 752 | | | 753 v v v 754 ------- ------ ------- 755 | TEK | | MSK | | EMSK | 756 ------- ------- -------- 758 Figure 1: Compound Keys 760 Furthermore, all compound keys CTK_i and all keys derived from it 761 SHOULD be derived in accordance to the guidelines for key derivations 762 and key hierarchies as specified in Section 4.2.1.1.3. In 763 particular, all derived keys MUST have a lifetime assigned that does 764 not exceed the lifetime of any key higher in the key hierarchy, and 765 MUST prevent domino effects where a compromise in one part of the 766 system leads to compromises in other parts of the system. 768 4.6.4. Peer Initiated 770 The tunnel method SHOULD allow for the peer to initiate an inner EAP 771 authentication in order to meet its policy requirements for 772 authenticating the server. 774 4.6.5. Method Meta-data 776 The tunnel method MUST allow for the communication of additional data 777 associated with an EAP method. This can be used to indicate whether 778 the authentication is for a user or a machine. This allows the EAP 779 server and peer to request and negotiate authentication specifically 780 for a user or machine. This is useful in the case of multiple inner 781 EAP authentications where the user and machine both need to be 782 authenticated. 784 5. IANA Considerations 786 This document has no IANA considerations. 788 6. Security Considerations 790 A tunnel method is often deployed to provide mutual authentication 791 between EAP Peer and EAP Server and to generate strong key material 792 for use in protecting lower layer protocols. In addition the tunnel 793 is used to protect the communication of additional data, including 794 peer identity between the EAP Peer and EAP Server from disclosure to 795 or modification by an attacker. These sections cover considerations 796 that affect the ability for a method to achieve these goals. 798 6.1. Cipher Suite Selection 800 TLS supports a wide variety of cipher suites providing a variety of 801 security properties. The selection of strong cipher suites is 802 critical to the security of the tunnel method. Selection of a cipher 803 suite with weak or no authentication, such as an anonymous Diffie- 804 Hellman based cipher suite will greatly increase the risk of system 805 compromise. Since a tunnel method uses the TLS tunnel to transport 806 data, the selection of a ciphersuite with weak data encryption and 807 integrity algorithms will also increase the vulnerability of the 808 method to attacks. 810 A tunnel protocol is prone to downgrading attacks if the tunnel 811 protocol supports any key establishment algorithm that can be broken 812 on-line. In a successful downgrading attack, an adversary breaks the 813 selected "weak" key establishment algorithm and optionally the "weak" 814 authentication algorithm without being detected. Here, "weak" refers 815 to a key establishment algorithm that can be broken in real-time, and 816 an authentication scheme that can be broken off-line, respectively. 817 See [KHLC07] for more details. The requirements in this document 818 disapprove the use of key establishment algorithms that can be broken 819 on-line. 821 Mutually anonymous tunnel protocols are prone to man-in-the-middle 822 attacks described in [KHLC07]. During such an attack, an adversary 823 establishes a tunnel with each the peer and the authentication 824 server, while peer and server believe that they established a tunnel 825 with each other. Once both tunnels have been established, the 826 adversary can eavesdrop on all communications within the tunnels, 827 i.e. the execution of the inner authentication method(s). 828 Consequently, the adversary can eavesdrop on the identifiers that are 829 exchanged as part of the EAP method and thus, the privacy of peer 830 and/or authentication server is compromised along with any other data 831 transmitted within the tunnels. This document requires server 832 authentication to avoid the risks associated with anonymous cipher 833 suites. 835 6.2. Tunneled Authentication 837 In many cases a tunnel method provides mutual authentication by 838 authenticating the server during tunnel establishment and 839 authenticating the peer within the tunnel using an EAP method. As 840 described in [TUNNEL-MITM], this mode of operation can allow tunnel 841 man-in-the-middle attackers to authenticate to the server as the peer 842 by tunneling the inner EAP protocol messages to and from a peer 843 executing the method outside a tunnel or with an untrustworthy 844 server. Cryptographic binding between the established keying 845 material from the inner authentication method(s) and the tunnel 846 protocol verifies that the endpoints of the tunnel and the inner 847 authentication method(s) are the same. This can thwart the attack if 848 the inner method derived keys of sufficient strength that they cannot 849 be broken in real-time. 851 In cases where the inner authentication method does not generate any 852 or only weak key material, security policies must be enforced such 853 that the peer cannot execute the inner method with the same 854 credentials outside a protective tunnel or with an untrustworthy 855 server. 857 6.3. Data External to Tunnel 859 The tunnel method will use data that is outside the TLS tunnel such 860 as the EAP type code or version numbers. If an attacker can 861 compromise the protocol by modifying these values the tunnel method 862 MUST protect this data from modification. 864 7. References 866 7.1. Normative References 868 [I-D.clancy-emu-chbind] 869 Clancy, C. and K. Hoeper, "Channel Binding Support for EAP 870 Methods", draft-clancy-emu-chbind-04 (work in progress), 871 November 2008. 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, March 1997. 876 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 877 Adams, "X.509 Internet Public Key Infrastructure Online 878 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 880 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 881 10646", STD 63, RFC 3629, November 2003. 883 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 884 Levkowetz, "Extensible Authentication Protocol (EAP)", 885 RFC 3748, June 2004. 887 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 888 Authentication Protocol (EAP) Method Requirements for 889 Wireless LANs", RFC 4017, March 2005. 891 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 892 Authorization, and Accounting (AAA) Key Management", 893 BCP 132, RFC 4962, July 2007. 895 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 896 Polk, "Server-Based Certificate Validation Protocol 897 (SCVP)", RFC 5055, December 2007. 899 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 900 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 902 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 903 Authentication Protocol (EAP) Key Management Framework", 904 RFC 5247, August 2008. 906 7.2. Informative References 908 [I-D.ietf-nea-pb-tnc] 909 Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture 910 Broker Protocol (PB) Compatible with TNC", 911 draft-ietf-nea-pb-tnc-02 (work in progress), 912 November 2008. 914 [I-D.mahy-eap-enrollment] 915 Mahy, R., "An Extensible Authentication Protocol (EAP) 916 Enrollment Method", draft-mahy-eap-enrollment-01 (work in 917 progress), March 2006. 919 [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 920 ICST QShine , August 2007. 922 [NIST SP 800-108] 923 Chen, L., "Recommendation for Key Derivation Using 924 Pseudorandom Functions", Draft NIST Special 925 Publication 800-108, April 2008. 927 [NIST SP 800-120] 928 Hoeper, K. and L. Chen, "Recommendation for EAP Methods 929 Used in Wireless Network Access Authentication", Draft 930 NIST Special Publication 800-120, December 2008. 932 [NIST SP 800-57] 933 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 934 "Recommendation for Key Management - Part 1: General 935 (Revised)", NIST Special Publication 800-57, part 1, 936 March 2007. 938 [NIST SP 800-57p3] 939 Barker, E., Burr, W., Jones, A., Polk, W., , S., and M. 940 Smid, "Recommendation for Key Management, Part 3 941 Application-Specific Key Management Guidance", Draft NIST 942 Special Publication 800-57,part 3, October 2008. 944 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 945 RFC 2246, January 1999. 947 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 948 Network Access Identifier", RFC 4282, December 2005. 950 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 951 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 953 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 954 Flexible Authentication via Secure Tunneling Extensible 955 Authentication Protocol Method (EAP-FAST)", RFC 4851, 956 May 2007. 958 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 959 "Transport Layer Security (TLS) Session Resumption without 960 Server-Side State", RFC 5077, January 2008. 962 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 963 Tardo, "Network Endpoint Assessment (NEA): Overview and 964 Requirements", RFC 5209, June 2008. 966 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 967 Protocol Tunneled Transport Layer Security Authenticated 968 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 970 [TUNNEL-MITM] 971 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 972 in Tunnelled Authentication Protocols", Cryptology ePrint 973 Archive: Report 2002/163, November 2002. 975 Appendix A. Changes from -01 976 o Added combined mutual authentication in section 3.1 977 o Changed reference from SP 800-52 to SP 800-57,part 3 978 o In section 6.2 changed terminology to tunnel MitM and security 979 policy enforcement 980 o Reworded text in section 3.2 to clarify MITM protection 981 o Added more specific text about derivation of the CTK 982 o Removed resource constrained section 983 o Added support for Non EAP authentication as a use for 984 extensibility 985 o Added text to emergency services section to emphasize that 986 sensitive information should not be sent if the server is 987 unauthenticated. 988 o Reworded TLS requirements 989 o Reworded external data protection requirements 990 o Added text to section 4.6 that states method must not be re- 991 defined inside the tunnel. 992 o Editorial fixes 994 Authors' Addresses 996 Katrin Hoeper 997 Motorola, Inc. 998 1301 E Algonquin Rd 999 Schaumburg, IL 60196 1000 USA 1002 Email: khoeper@motorola.com 1004 Stephen Hanna 1005 Juniper Networks 1006 3 Beverly Road 1007 Bedford, MA 01730 1008 USA 1010 Email: shanna@juniper.net 1012 Hao Zhou 1013 Cisco Systems, Inc. 1014 4125 Highlander Parkway 1015 Richfield, OH 44286 1016 USA 1018 Email: hzhou@cisco.com 1019 Joseph Salowey (editor) 1020 Cisco Systems, Inc. 1021 2901 3rd. Ave 1022 Seattle, WA 98121 1023 USA 1025 Email: jsalowey@cisco.com