--- 1/draft-ietf-emu-eaptunnel-req-01.txt 2009-02-27 03:12:06.000000000 +0100 +++ 2/draft-ietf-emu-eaptunnel-req-02.txt 2009-02-27 03:12:06.000000000 +0100 @@ -1,142 +1,158 @@ EMU Working Group K. Hoeper -Internet-Draft NIST +Internet-Draft Motorola, Inc. Intended status: Informational S. Hanna -Expires: May 4, 2009 Juniper Networks +Expires: August 31, 2009 Juniper Networks H. Zhou J. Salowey, Ed. Cisco Systems, Inc. - October 31, 2008 + February 27, 2009 - Requirements for an Tunnel Based EAP Method - draft-ietf-emu-eaptunnel-req-01.txt + Requirements for a Tunnel Based EAP Method + draft-ietf-emu-eaptunnel-req-02.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. This document may contain material + from IETF Documents or IETF Contributions published or made publicly + available before November 10, 2008. The person(s) controlling the + copyright in some of this material may not have granted the IETF + Trust the right to allow modifications of such material outside the + IETF Standards Process. Without obtaining an adequate license from + the person(s) controlling the copyright in such materials, this + document may not be modified outside the IETF Standards Process, and + derivative works of it may not be created outside the IETF Standards + Process, except to format it for publication as an RFC or to + translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 4, 2009. + This Internet-Draft will expire on August 31, 2009. Copyright Notice + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. - Copyright (C) The IETF Trust (2008). + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 + 2. Conventions Used In This Document . . . . . . . . . . . . . . 5 - 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Password Authentication . . . . . . . . . . . . . . . . . 5 - 3.2. Protect Weak EAP Methods . . . . . . . . . . . . . . . . . 5 - 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 5 - 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6 - 3.5. Emergency Services Authentication . . . . . . . . . . . . 6 - 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 6 - 3.7. Resource Constrained Environments . . . . . . . . . . . . 6 - 3.8. Client Authentication During Tunnel Establishment . . . . 7 - 3.9. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 + 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 + 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 + 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 + 3.5. Emergency Services Authentication . . . . . . . . . . . . 7 + 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 + 3.7. Client Authentication During Tunnel Establishment . . . . 8 + 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 - 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 7 - 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 8 - 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 8 - 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 9 - 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 9 - 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 9 - 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 9 - 4.2.1.1.3. Tunnel Authentication and Key Establishment . 9 - 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11 - 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11 - 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 - 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 - 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 - 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 - 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 - 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12 - 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 - 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13 - 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 - 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 - 4.3.6. Internationalization of Display Strings . . . . . . . 13 - 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 + 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 8 + 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 8 + 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9 + 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 + 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 + 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 + 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 + 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10 + 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 + 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 + 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 13 + 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 13 + 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 13 + 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 13 + 4.2.3. Protection of Data External to Tunnel . . . . . . . . 13 + 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13 + 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 14 + 4.3.2. Request/Challenge Response Operation . . . . . . . . . 14 + 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 14 + 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 14 + 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 14 + 4.3.6. Internationalization of Display Strings . . . . . . . 15 + 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 15 4.5. Requirements Associated with Carrying Username and - Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14 - 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14 - 4.5.1.3. Server Credential Revocation Checking . . . . . . 14 - 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 - 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 - 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15 - 4.6. Requirements Associated with Carrying EAP Methods . . . . 15 - 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 15 - 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 15 - 4.6.3. Cryptographic Binding with TLS Tunnel . . . . . . . . 15 - 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 - 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17 + Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15 + 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 + 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 + 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 16 + 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 16 + 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16 + 4.6. Requirements Associated with Carrying EAP Methods . . . . 16 + 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 + 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 + 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 17 + 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 18 + 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 17 - 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 18 - 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 19 + 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 20 + 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 - Intellectual Property and Copyright Statements . . . . . . . . . . 23 + Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Running EAP methods within a TLS protected tunnel has been deployed in several different solutions. EAP methods supporting this include - PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. There have been various - reasons for employing a protected tunnel for EAP processes. They - include protecting weak authentication exchanges, such as username - and password. In addition a protected tunnel can provide means to - provide peer identity protection and EAP method chaining. Finally, - systems have found it useful to transport additional types of data - within the protected tunnel. + PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this has + worked well so there is consensus to continue to use TLS as the basis + for a tunnel method. There have been various reasons for employing a + protected tunnel for EAP processes. They include protecting weak + authentication exchanges, such as username and password. In addition + a protected tunnel can provide means to provide peer identity + protection and EAP method chaining. Finally, systems have found it + useful to transport additional types of data within the protected + tunnel. This document describes the requirements for an EAP tunnel method as well as for a password protocol supporting legacy password verification within the tunnel method. 2. Conventions Used In This Document Because this specification is an informational specification (not able to directly use [RFC2119]), the following capitalized words are used to express requirements language used in this specification. @@ -154,54 +170,70 @@ MAY - indicates a willingness to allow an optional outcome Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" carry their normal meaning and are not subject to these definitions. 3. Use Cases To motivate and explain the requirements in this document, a representative set of use cases for the EAP tunnel method are - supplied here. The candidate tunnel method is expected to meet all - of the use cases marked as MUST. + supplied here. The candidate tunnel method is expected to support + all of the use cases marked as MUST. 3.1. Password Authentication Many legacy systems only support user authentication with passwords. Some of these systems require transport of the actual username and password to the authentication server. This is true for systems where the authentication server does not have access to the cleartext password or a consistent transform of the cleartext password. Example of such systems are one time password (OTP) systems and other systems where the username and password are submitted to an external - party for validation. The tunnel method MUST meet this use case. + party for validation. The tunnel method MUST support this use case. However, it MUST NOT expose the username and password to untrusted parties and it MUST provide protection against man-in-the-middle and - dictionary attacks. + dictionary attacks. The combination of the tunnel authentication and + password authentication MUST enable mutual authentication. Since EAP authentication occurs before network access is granted the tunnel method SHOULD enable an inner exchange to provide support for minimal password management tasks including password change, "new PIN mode", and "next token mode" required by some systems. -3.2. Protect Weak EAP Methods +3.2. Protection of Weak EAP Methods Some existing EAP methods have vulnerabilities that could be eliminated or reduced by running them inside a protected tunnel. For example, a method such as EAP-MD5 does not provide mutual - authentication or protection from dictionary attacks. In addition, - tunneled EAP methods are subject to a specific form of man-in-the- - middle attack described in [TUNNEL-MITM]. + authentication or protection from dictionary attacks. Without extra + protection, tunnel-based EAP methods are vulnerable to a special type + of man-in-the-middle attacks documented in [TUNNEL-MITM]. This + attack is referred to as "tunnel MitM attack" in the remainder of + this document. The additional protection needed to thwart tunnel + MitM attacks depends on the inner method executed within the tunnel. + In particular, when weak methods are used, security policies + enforcing that such methods can only be executed inside a tunnel but + never outside one are required to mitigate the attack. On the other + hand, a technical solution (so-called cryptographic bindings) can be + used whenever the inner method is not susceptible to attacks outside + a tunnel and derives keying material. Only the latter mitigation + technique can be made an actual requirement for tunnel-based EAP + methods (see Section 4.6.3), while security policies are outside the + scope of this requirement draft. Please refer to [NIST SP 800-120] + for a discussion on security policies and complete solutions for + thwarting tunnel MitM attacks. - The tunnel method MUST support protection of weak inner methods and - protect against man-in-the-middle attacks associated with tunneled - authentication. + The tunnel method MUST support protection of weak EAP methods, + including cryptographic protection from tunnel MitM attacks. In + combination with an appropriate security policy this will thwart MitM + attacks against inner methods. 3.3. Chained EAP Methods Several circumstances are best addressed by using chained EAP methods. For example, it may be desirable to authenticate the user and also authenticate the device that he or she is using. However, chained EAP methods from different conversations can be re-directed into the same conversation by an attacker giving the authenticator the impression that both conversations terminate at the same end- point. Cryptographic binding can be used to bind the results of key @@ -230,75 +262,62 @@ user to be able to gain access to the network to make an emergency telephone call. To avoid eavesdropping on this call, it's best to negotiate link layer security as with any other authentication. Therefore, the tunnel method SHOULD allow anonymous peers or server- only authentication, but still derive keys that can be used for link layer security. The tunnel method MAY also allow for the bypass of server authentication processing on the client. Forgoing authentication increases the chance of man-in-the-middle and other types of attacks that can compromise the derived keys used for link - layer security. + layer security. In addition, passwords and other sensitive + information must not be disclosed to an unauthenticated or + unauthorized server. 3.6. Network Endpoint Assessment The Network Endpoint Assessment (NEA) protocols and reference model described in [RFC5209] provide a standard way to check the health ("posture") of a device at or after the time it connects to a network. If the device does not comply with the network's requirements, it can be denied access to the network or granted limited access to remediate itself. EAP is a convenient place for conducting an NEA exchange. The tunnel method SHOULD support carrying NEA protocols such as PB- TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel method, these protocols may be required to be carried in an EAP method. -3.7. Resource Constrained Environments - - A growing number of "resource constrained" devices (e.g. printers and - phones) are connecting to IP networks and those networks increasingly - require EAP authentication to gain access. Therefore, it is natural - to expect that new EAP methods be designed to work as well as - possible with these devices. - - For the purposes of this document, the phrase "resource constrained" - means any combination of the following constraints: little processing - power, small amounts of memory (both ROM and RAM), small amounts of - long-term mutable storage (e.g. flash or hard drive) or none at all, - and constrained power usage (perhaps due to small battery). - - The tunnel method SHOULD be designed so it can be configured to work - with "resource constrained" devices, when possible. - -3.8. Client Authentication During Tunnel Establishment +3.7. Client Authentication During Tunnel Establishment In cases where client authentication can be performed as part of the tunnel establishment it is efficient for the tunnel method to allow - this. The tunnel MUST be capable of providing client side + this. The tunnel method MUST be capable of providing client side authentication during tunnel establishment. -3.9. Extensibility +3.8. Extensibility The tunnel method MUST provide extensibility so that additional types of data can be carried inside the tunnel in the future. This removes the need to develop new tunneling methods for specific purposes. One example of a application for extensibility is credential provisioning. When a peer has authenticated with EAP, this is a convenient time to distribute credentials to that peer that may be used for later authentication exchanges. For example, the authentication server can provide a private key or shared key to the peer that can be used by the peer to perform rapid re-authentication or roaming. In addition there have been proposals to perform - enrollment within EAP, such as [I-D.mahy-eap-enrollment]. + enrollment within EAP, such as [I-D.mahy-eap-enrollment]. Another + use for extensibility is support for authentication frameworks other + than EAP. 4. Requirements 4.1. General Requirements 4.1.1. RFC Compliance The tunnel method MUST include a Security Claims section with all security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC @@ -344,23 +363,22 @@ requirements contained in this specification then that method SHOULD be preferred over a new method. Even if minor modifications or extensions to an existing tunnel method are needed, this method SHOULD be preferred over a completely new method so that the advantage of accumulated deployment experience and security analysis can be gained. 4.2. Tunnel Requirements - Existing tunnel methods make use of TLS [RFC5246] to provide the - protected tunnel. In general this has worked well so there is - consensus to continue to use TLS as the basis for a tunnel method. + The following section discusses requirements for TLS Tunnel + Establishment. 4.2.1. TLS Requirements The tunnel based method MUST support TLS version 1.2 [RFC5246] and SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to enable the possibility of backwards compatibility with existing deployments. The following section discusses requirements for TLS Tunnel Establishment. 4.2.1.1. Cipher Suites @@ -443,23 +461,24 @@ o Key freshness, i.e. EAP peer and EAP server are assured that the derived keys are fresh and the re-use of expired key material is prevented. The freshness property is typically achieved by using one or more of the following techniques: nonces, sequence numbers, timestamps. The mandatory to implement cipher suites MUST NOT include "export strength" cipher suites, cipher suites providing mutually anonymous authentication or static Diffie-Hellman cipher suites. NIST - publication [NIST SP 800-52] can be consulted for a list of - acceptable TLS v1.0 cipher suites and [NIST SP 800-108] for - additional information on secure key derivation. + publication [NIST SP 800-57p3] can be consulted for a list of + acceptable TLS v1.0, v1.1 and v 1.2 cipher suites and NIST + publication [NIST SP 800-108] for additional information on secure + key derivation. In addition a tunnel method SHOULD provide cipher suites to meet the following additional recommendations for good key establishment algorithms: o Key control , i.e., EAP peer and authentication server each contribute to the key computation of the tunnel key. This property prevents that a single protocol participant controls the value of an established key. In that way, protocol participants can ensure that generated keys are fresh and have good random @@ -513,23 +532,25 @@ 4.2.2. Fragmentation Tunnel establishment sometimes requires the exchange of information that exceeds what can be carried in a single EAP message. In addition information carried within the tunnel may also exceed this limit. Therefore a tunnel method MUST support fragmentation and reassembly. 4.2.3. Protection of Data External to Tunnel - A tunnel method MUST provide protection of any data external to the - TLS tunnel that can cause a problem if it is modified by an attacker. - This may include data such as type codes and version numbers + An attacker in the middle can modify clear text values such as + protocol version and type code information communicated outside the + TLS tunnel. If modification of this information can cause + vulnerabilities, the tunnel method MUST provide protection against + modification of this data. 4.3. Tunnel Payload Requirements This section describes the payload requirements inside the tunnel. These requirements frequently express features that a candidate protocol must be capable of offering so that a deployer can decide whether to make use of that feature. This section does not state requirements about what features of each protocol must be used during a deployment. @@ -616,21 +637,21 @@ The clear text password exchange MUST be integrity and confidentiality protected. As long as the password exchange occurs inside an authenticated and encrypted tunnel, this requirement is met. 4.5.1.2. Authentication of Server The EAP server MUST be authenticated before the peer can send the clear text password to the server. -4.5.1.3. Server Credential Revocation Checking +4.5.1.3. Server Certificate Revocation Checking In some cases, the EAP peer needs to present its password to the server before it has network access to check the revocation status of the server's credentials. Therefore, the tunnel method MUST support mechanisms to check the revocation status of a credential. The tunnel method SHOULD make use of Online Certificate Status Protocol (OCSP) [RFC2560] or Server-based Certificate Validation Protocol (SCVP) [RFC5055] to obtain the revocation status of the EAP server certificate. @@ -656,92 +677,100 @@ 4.5.4. Password Change The password authentication exchange MUST support password change, as well as other multiple round trips exchanges like new pin mode and next token mode for OTP verifiers. 4.6. Requirements Associated with Carrying EAP Methods The tunnel method MUST be able to carry inner EAP methods without - modifying them. + modifying them. EAP methods MUST NOT be redefined inside the tunnel. 4.6.1. Method Negotiation The tunnel method MUST support the protected negotiation of the inner EAP method. It MUST NOT allow the inner EAP method negotiation to be downgraded or manipulated by intermediaries. 4.6.2. Chained Methods The tunnel method MUST support the chaining of multiple EAP methods. The tunnel method MUST allow for the communication of intermediate result and verification of compound binding between executed inner methods when chained methods are employed. -4.6.3. Cryptographic Binding with TLS Tunnel +4.6.3. Cryptographic Binding with the TLS Tunnel The tunnel method MUST provide a mechanism to bind the tunnel protocol and the inner EAP method. This property is referred to as - cryptographic binding. Without such bindings attacks are feasible on - tunnel methods [TUNNEL-MITM] and chained methods. + cryptographic binding. Such bindings are an important tool for + mitigating the tunnel MitM attacks on tunnel methods described in + [TUNNEL-MITM]. Cryptographic bindings enable the complete prevention + of tunnel MitM attacks without the need of additional security + policies as long as the inner method derives keys and is not + vulnerable to attacks outside a protected tunnel [KHLC07]. Even + though weak or non-key deriving inner methods may be permitted, and + thus security policies preventing tunnel MitM attacks are still + necessary, the tunnel method MUST provide cryptographic bindings, + because only this allows migrating to more secure, policy-independent + implementations. Cryptographic bindings are typically achieved by securely mixing the established keying material (say tunnel key TK) from the tunnel protocol with the established keying material (say method key MK) from the inner authentication method(s) in order to derive fresh keying material. If chained EAP methods are executed in the tunnel, - all derived inner keys are combined to one method key MK. The keying - material derived from mixing tunnel and method keys is also referred - to as compound tunnel key (CTK). In particular, CTK is used to - derive the EAP MSK, EMSK and other transient keys (TEK), such as - transient encryption keys and integrity protection keys. The key - hierarchy for tunnel methods executions that derive compound keys for - the purpose of cryptographic binding is depicted in Figure 1. + all derived inner keys are combined with the tunnel key to create a + new compound tunnel key (CTK). In particular, CTK is used to derive + the EAP MSK, EMSK and other transient keys (TEK), such as transient + encryption keys and integrity protection keys. The key hierarchy for + tunnel methods executions that derive compound keys for the purpose + of cryptographic binding is depicted in Figure 1. + + In the case of the sequential executions of n inner methods, a + chained compound key CTK_i MUST be computed upon the completion of + each inner method i such that it contains the compound key of all + previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n + and CTK_0=TK, where f() is a good key derivation function, such as + one that complies with [NIST SP 800-108]. CTK_n SHOULD serve as the + key to derive further keys. Figure 1 depicts the key hierarchy in + the case of a single inner method. Transient keys derived from the + compound key CTK are used in a cryptographic protocol to verify the + integrity of the tunnel and the inner authentication method. ----------- | TK | MK | ----------- | | v v -------- | CTK | -------- | v ---------------- | | | v v v ------- ------ ------- | TEK | | MSK | | EMSK | ------- ------- -------- Figure 1: Compound Keys - For every key deriving inner EAP method that completes successfully - within the tunnel cryptographic binding MUST be performed similar to - the following: - - o compute a compound key CTK using the keying material from tunnel - protocol and all tunneled inner authentication method(s) as inputs - - o use compound key CTK to derive transient keys for use in a - cryptographic protocol that verifies the integrity of the tunnel - and the inner authentication method. - - Furthermore, the compound key CTK and all keys derived from it SHOULD - be derived in accordance to the guidelines for key derivations and - key hierarchies as specified in Section 4.2.1.1.3. In particular, - all derived keys MUST have a lifetime assigned that does not exceed - the lifetime of any key higher in the key hierarchy, and MUST prevent - domino effects where a compromise in one part of the system leads to - compromises in other parts of the system. + Furthermore, all compound keys CTK_i and all keys derived from it + SHOULD be derived in accordance to the guidelines for key derivations + and key hierarchies as specified in Section 4.2.1.1.3. In + particular, all derived keys MUST have a lifetime assigned that does + not exceed the lifetime of any key higher in the key hierarchy, and + MUST prevent domino effects where a compromise in one part of the + system leads to compromises in other parts of the system. 4.6.4. Peer Initiated The tunnel method SHOULD allow for the peer to initiate an inner EAP authentication in order to meet its policy requirements for authenticating the server. 4.6.5. Method Meta-data The tunnel method MUST allow for the communication of additional data @@ -801,51 +830,52 @@ and/or authentication server is compromised along with any other data transmitted within the tunnels. This document requires server authentication to avoid the risks associated with anonymous cipher suites. 6.2. Tunneled Authentication In many cases a tunnel method provides mutual authentication by authenticating the server during tunnel establishment and authenticating the peer within the tunnel using an EAP method. As - described in [TUNNEL-MITM], this mode of operation can allow a man- - in-the-middle to authenticate to the server as the peer by tunneling - the inner EAP protocol messages to and from a peer executing the - method outside a tunnel or with an untrustworthy server. - Cryptographic binding between the established keying material from - the inner authentication method(s) and the tunnel protocol verifies - that the endpoints of the tunnel and the inner authentication - method(s) are the same. This can thwart the attack if the inner - method derived keys of sufficient strength that they cannot be broken - in real-time. + described in [TUNNEL-MITM], this mode of operation can allow tunnel + man-in-the-middle attackers to authenticate to the server as the peer + by tunneling the inner EAP protocol messages to and from a peer + executing the method outside a tunnel or with an untrustworthy + server. Cryptographic binding between the established keying + material from the inner authentication method(s) and the tunnel + protocol verifies that the endpoints of the tunnel and the inner + authentication method(s) are the same. This can thwart the attack if + the inner method derived keys of sufficient strength that they cannot + be broken in real-time. In cases where the inner authentication method does not generate any - or only weak key material care must be taken to ensure that the peer - does not execute the inner method with the same credentials outside a - protective tunnel or with an untrustworthy server. + or only weak key material, security policies must be enforced such + that the peer cannot execute the inner method with the same + credentials outside a protective tunnel or with an untrustworthy + server. 6.3. Data External to Tunnel The tunnel method will use data that is outside the TLS tunnel such as the EAP type code or version numbers. If an attacker can compromise the protocol by modifying these values the tunnel method - MUST protect this data. + MUST protect this data from modification. 7. References 7.1. Normative References [I-D.clancy-emu-chbind] Clancy, C. and K. Hoeper, "Channel Binding Support for EAP - Methods", draft-clancy-emu-chbind-03 (work in progress), - October 2008. + Methods", draft-clancy-emu-chbind-04 (work in progress), + November 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. @@ -871,45 +901,52 @@ [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. 7.2. Informative References [I-D.ietf-nea-pb-tnc] Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", - draft-ietf-nea-pb-tnc-01 (work in progress), July 2008. + draft-ietf-nea-pb-tnc-02 (work in progress), + November 2008. [I-D.mahy-eap-enrollment] Mahy, R., "An Extensible Authentication Protocol (EAP) Enrollment Method", draft-mahy-eap-enrollment-01 (work in progress), March 2006. [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", ICST QShine , August 2007. [NIST SP 800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", Draft NIST Special Publication 800-108, April 2008. - [NIST SP 800-52] - Chernick, C., Edington III, C., Fanto, M., and R. - Rosenthal, "Guidelines for the Selection and Use of - Transport Layer Security (TLS) Implementations", NIST - Special Publication 800-52, June 2005. + [NIST SP 800-120] + Hoeper, K. and L. Chen, "Recommendation for EAP Methods + Used in Wireless Network Access Authentication", Draft + NIST Special Publication 800-120, December 2008. [NIST SP 800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General - (Revised)", NIST Special Publication 800-57, March 2007. + (Revised)", NIST Special Publication 800-57, part 1, + March 2007. + + [NIST SP 800-57p3] + Barker, E., Burr, W., Jones, A., Polk, W., , S., and M. + Smid, "Recommendation for Key Management, Part 3 + Application-Specific Key Management Guidance", Draft NIST + Special Publication 800-57,part 3, October 2008. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. @@ -928,29 +965,48 @@ [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. [TUNNEL-MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunnelled Authentication Protocols", Cryptology ePrint Archive: Report 2002/163, November 2002. +Appendix A. Changes from -01 + o Added combined mutual authentication in section 3.1 + o Changed reference from SP 800-52 to SP 800-57,part 3 + o In section 6.2 changed terminology to tunnel MitM and security + policy enforcement + o Reworded text in section 3.2 to clarify MITM protection + o Added more specific text about derivation of the CTK + o Removed resource constrained section + o Added support for Non EAP authentication as a use for + extensibility + o Added text to emergency services section to emphasize that + sensitive information should not be sent if the server is + unauthenticated. + o Reworded TLS requirements + o Reworded external data protection requirements + o Added text to section 4.6 that states method must not be re- + defined inside the tunnel. + o Editorial fixes + Authors' Addresses Katrin Hoeper - NIST - 100 Bureau Drive, MS: 8930 - Gaithersburg, MD 20899 + Motorola, Inc. + 1301 E Algonquin Rd + Schaumburg, IL 60196 USA - Email: khoeper@nist.gov + Email: khoeper@motorola.com Stephen Hanna Juniper Networks 3 Beverly Road Bedford, MA 01730 USA Email: shanna@juniper.net Hao Zhou @@ -960,55 +1016,10 @@ USA Email: hzhou@cisco.com Joseph Salowey (editor) Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA Email: jsalowey@cisco.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).