--- 1/draft-ietf-emu-eaptunnel-req-06.txt 2010-06-24 07:12:20.000000000 +0200 +++ 2/draft-ietf-emu-eaptunnel-req-07.txt 2010-06-24 07:12:20.000000000 +0200 @@ -1,22 +1,22 @@ EMU Working Group K. Hoeper Internet-Draft Motorola, Inc. Intended status: Informational S. Hanna -Expires: November 15, 2010 Juniper Networks +Expires: December 26, 2010 Juniper Networks H. Zhou J. Salowey, Ed. Cisco Systems, Inc. - May 14, 2010 + June 24, 2010 Requirements for a Tunnel Based EAP Method - draft-ietf-emu-eaptunnel-req-06.txt + draft-ietf-emu-eaptunnel-req-07.txt 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. Status of this Memo @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on November 15, 2010. + This Internet-Draft will expire on December 26, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -89,52 +89,52 @@ 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 . . . . . . 11 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 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. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 4.3.6. Internationalization of Display Strings . . . . . . . 14 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 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.2. Authentication of Server . . . . . . . . . . . . . 15 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 - 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15 + 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 . . . . . . 16 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 - 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17 + 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 6.4. Separation of TLS Tunnel and Inner Authentication - Termination . . . . . . . . . . . . . . . . . . . . . . . 19 + Termination . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23 Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23 @@ -243,21 +243,21 @@ 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 being used. 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 chained key generating methods together or to an encompassing tunnel. The tunnel method MUST support chained EAP methods while including - strong protection against attacks on method chaining. + protection against attacks on method chaining. 3.4. Identity Protection When performing an EAP authentication, the peer may want to protect its identity and only disclose it to a trusted EAP server. This helps to maintain peer privacy. The tunnel method MUST support identity protection, therefore the identity of the peer used for authentication purposes MUST NOT be obtainable by any entity other than the EAP server terminating the @@ -331,22 +331,22 @@ 3.9. Certificate-less Authentication and Generic EAP Method Extension In some cases the peer will not have a way to verify a server certificate and in some cases a server might not have a certificate to verify. Therefore, it is desirable to support certificate-less authentication. An application for this is credential provisioning where the peer and server authenticate each other with a shared password and credentials for subsequent authentication (e.g. a key pair and certificate or a shared key) can be passed inside the - tunnel. Another application is to extend existing strong EAP methods - with new features such as channel bindings. + tunnel. Another application is to extend existing EAP methods with + new features such as channel bindings. Great care must be taken when attempting to perform certificate-less authentication. One way of doing it is to establish the tunnel without full server or client verification and inside the tunnel use an EAP method that performs mutual authentication and key derivation. If this technique is used the inner EAP method MUST provide resistance to dictionary attack and a cryptographic binding between the inner method and the tunnel method MUST be established. In addition the cipher suite used to establish the tunnel MUST derive the master key using contribution from both client and server, as in @@ -421,22 +421,22 @@ has been maliciously altered by another party. Integrity checks prevent downgrading attacks only if the derived integrity keys and the employed integrity algorithms cannot be broken in real-time. See Section 6.1 or [KHLC07] for more information on this. Hence, the tunnel method MUST provide integrity protected cipher suite negotiation with secure integrity algorithms and integrity keys. TLS provides protected cipher suite negotiation as long as all the - cipher suites supported provide strong authentication, key - establishment and data integrity protection. + cipher suites supported provide authentication, key establishment and + data integrity protection as discussed in Section 6.1. 4.2.1.1.2. Tunnel Data Protection Algorithms In order to prevent attacks on the cryptographic algorithms employed by inner authentication methods, a tunnel protocol's protection needs to provide a basic level of algorithm strength. The tunnel method MUST provide at least one mandatory to implement cipher suite that provides the equivalent security of 128-bit AES for encryption and message authentication. See Part 1 of the NIST Recommendation for Key Management [NIST SP 800-57] for a discussion of the relative @@ -466,21 +466,22 @@ EAP Methods Used in Wireless Network Access Authentication [NIST SP 800-120]. 4.2.1.2. Tunnel Replay Protection In order to prevent replay attacks on a tunnel protocol, the message authentication MUST be generated using a time-variant input such as timestamps, sequence numbers, nonces, or a combination of these so that any re-use of the authentication data can be detected as invalid. TLS provides sufficient replay protection to meet this - requirements as long as strong ciphersuites are used. + requirements as long as weak cipher suites discussed in Section 6.1 + are avoided. 4.2.1.3. TLS Extensions In order to meet the requirements in this document TLS extensions MAY be used. For example, TLS extensions may be useful in providing certificate revocation information via the TLS OCSP extension (thus meeting the requirement in Section 4.5.1.3). 4.2.1.4. Peer Identity Privacy @@ -703,22 +704,22 @@ 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 Recommendation for Key Derivation Using + and CTK_0=TK, where f() is a key derivation function, such as one + that complies with NIST Recommendation for Key Derivation Using Pseudorandom Functions [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 | ----------- | | @@ -762,38 +763,38 @@ multiple inner EAP authentications where the user and machine both need to be authenticated. 5. IANA Considerations This document has no IANA considerations. 6. Security Considerations A tunnel method is often deployed to provide mutual authentication - between EAP Peer and EAP Server and to generate strong key material - for use in protecting lower layer protocols. In addition the tunnel - is used to protect the communication of additional data, including - peer identity between the EAP Peer and EAP Server from disclosure to - or modification by an attacker. These sections cover considerations + between EAP Peer and EAP Server and to generate key material for use + in protecting lower layer protocols. In addition the tunnel is used + to protect the communication of additional data, including peer + identity between the EAP Peer and EAP Server from disclosure to or + modification by an attacker. These sections cover considerations that affect the ability for a method to achieve these goals. 6.1. Cipher Suite Selection TLS supports a wide variety of cipher suites providing a variety of - security properties. The selection of strong cipher suites is - critical to the security of the tunnel method. Selection of a cipher - suite with weak or no authentication, such as an anonymous Diffie- - Hellman based cipher suite will greatly increase the risk of system - compromise. Since a tunnel method uses the TLS tunnel to transport - data, the selection of a ciphersuite with weak data encryption and - integrity algorithms will also increase the vulnerability of the - method to attacks. + security properties. The selection of cipher suites is critical to + the security of the tunnel method. Selection of a cipher suite with + weak or no authentication, such as an anonymous Diffie- Hellman based + cipher suite will greatly increase the risk of system compromise. + Since a tunnel method uses the TLS tunnel to transport data, the + selection of a ciphersuite with weak data encryption and integrity + algorithms will also increase the vulnerability of the method to + attacks. A tunnel protocol is prone to downgrading attacks if the tunnel protocol supports any key establishment algorithm that can be broken on-line. In a successful downgrading attack, an adversary breaks the selected "weak" key establishment algorithm and optionally the "weak" authentication algorithm without being detected. Here, "weak" refers to a key establishment algorithm that can be broken in real-time, and an authentication scheme that can be broken off-line, respectively. See [KHLC07] for more details. The requirements in this document disapprove the use of key establishment algorithms that can be broken