--- 1/draft-ietf-emu-eaptunnel-req-00.txt 2008-11-01 08:12:03.000000000 +0100 +++ 2/draft-ietf-emu-eaptunnel-req-01.txt 2008-11-01 08:12:03.000000000 +0100 @@ -1,22 +1,22 @@ EMU Working Group K. Hoeper Internet-Draft NIST Intended status: Informational S. Hanna -Expires: December 27, 2008 Juniper Networks +Expires: May 4, 2009 Juniper Networks H. Zhou J. Salowey, Ed. Cisco Systems, Inc. - June 25, 2008 + October 31, 2008 Requirements for an Tunnel Based EAP Method - draft-ietf-emu-eaptunnel-req-00.txt + draft-ietf-emu-eaptunnel-req-01.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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -27,21 +27,21 @@ 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 December 27, 2008. + This Internet-Draft will expire on May 4, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). 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 @@ -54,94 +54,93 @@ 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 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. Credential Provisioning and Enrollment . . . . . . . . . . 7 - 3.8. Resource Constrained Environments . . . . . . . . . . . . 7 - 3.9. Client Authentication During Tunnel Establishment . . . . 7 - 3.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 + 3.7. Resource Constrained Environments . . . . . . . . . . . . 6 + 3.8. Client Authentication During Tunnel Establishment . . . . 7 + 3.9. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 8 - 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 8 + 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 + 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 8 - 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 9 + 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 . . . . . . 10 - 4.2.1.1.3. Tunnel Authentication and Key Establishment . 10 - 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 - 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 + 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. EAP Header Protection . . . . . . . . . . . . . . . . 12 + 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 - 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 + 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 . . . . . . . 14 + 4.3.6. Internationalization of Display Strings . . . . . . . 13 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 . . . . . . . . . . 15 - 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 - 4.5.1.3. Server Credential Revocation Checking . . . . . . 15 + 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 . . . . 16 - 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 - 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 - 4.6.3. Cryptographic Binding with TLS Tunnel . . . . . . . . 16 + 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 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 6.1. Ciphersuite Selection . . . . . . . . . . . . . . . . . . 18 - 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 - 6.3. Outer EAP Method Header . . . . . . . . . . . . . . . . . 19 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 17 + 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 18 + 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 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 [I-D.funk-eap-ttls-v0] 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 a 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]. 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 databases - within the tunnel method. + 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. Use of each capitalized word within a sentence or phrase carries the following meaning during the EMU WG's method selection process: MUST - indicates an absolute requirement @@ -173,23 +172,23 @@ 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. 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. Since EAP authentication occurs before network access is granted the - tunnel method SHOULD provide support for minimal password management - tasks including password change, "new PIN mode", and "next token - mode" required by some systems. + 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 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]. @@ -214,172 +213,162 @@ 3.4. Identity Protection When performing an EAP authentication, the peer may want to protect its identity, only disclosing its identity to a trusted backend authentication server. This helps to maintain the privacy of the peer's identity. The tunnel method MUST support identity protection, ensuring that peer identity is not disclosed to the authenticator and any other intermediaries before the server that terminates the tunnel method. - If an inner method also provides identity protection, this protection - MUST extend all the way to the server that terminates that inner - method. Note that the peer may need to expose the realm portion of - the EAP outer identity in the NAI [RFC4282] in a roaming scenario in - order to reach the appropriate authentication server. + Note that the peer may need to expose the realm portion of the EAP + outer identity in the NAI [RFC4282] in a roaming scenario in order to + reach the appropriate authentication server. 3.5. Emergency Services Authentication When wireless VOIP service is provided, some regulations require any 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. 3.6. Network Endpoint Assessment The Network Endpoint Assessment (NEA) protocols and reference model - described in [I-D.ietf-nea-requirements] 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. + 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. Credential Provisioning and Enrollment - - 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]. - - The tunnel method SHOULD support carrying credential distribution - protocols. - -3.8. Resource Constrained Environments +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.9. Client Authentication During Tunnel Establishment +3.8. 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 authentication during tunnel establishment. -3.10. Extensibility +3.9. 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]. + 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 3748 that tunnel methods MUST support protection against man-in-the- middle attacks. Furthermore, all tunnel methods MUST support identity protection as specified in Section 7.3 in RFC 3748. The tunnel method MUST be unconditionally compliant with RFC 4017 [RFC4017] (using the definition of "unconditionally compliant" contained in section 1.1 of RFC 4017). This means that the method MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT requirements in RFC 4017. The tunnel method MUST meet all the EAP method requirements contained - in the EAP Key Management Framework draft [I-D.ietf-eap-keying] or - its successor. The tunnel method MUST include MSK and EMSK - generation. This will enable the tunnel method to properly fit into - the EAP key management framework, maintaining all of the security - properties and guarantees of that framework. + in the EAP Key Management Framework [RFC5247] or its successor. The + tunnel method MUST include MSK and EMSK generation. This will enable + the tunnel method to properly fit into the EAP key management + framework, maintaining all of the security properties and guarantees + of that framework. The tunnel method MUST NOT be tied to any single cryptographic algorithm. Instead, it MUST support run-time negotiation to select among an extensible set of cryptographic algorithms. This "cryptographic algorithm agility" provides several advantages. Most important, when a weakness in an algorithm is discovered or increased processing power overtakes an algorithm, users can easily transition to a new algorithm. Also, users can choose the algorithm that best meets their needs. The tunnel method MUST meet requirements pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. This includes: cryptographic algorithm independence; strong, fresh session keys; replay detection; keying material confidentiality and integrity; - confirm cipher suite selection; and uniquely named keys. In - addition, the tunnel method MUST support EAP channel bindings to - enable a system based on EAP to meet the additional requirements in - Section 3 of RFC 4962. + confirm cipher suite selection; and uniquely named keys. 4.1.2. Draw from Existing Work Several existing tunnel methods are already in widespread usage: EAP- - FAST [RFC4851], EAP-TTLS [I-D.funk-eap-ttls-v0], and PEAP. - Considerable experience has been gained from various deployments with - these methods. This experience SHOULD be considered when evaluating - tunnel methods. If one of these existing tunnel methods can meet the + FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable + experience has been gained from various deployments with these + methods. This experience SHOULD be considered when evaluating tunnel + methods. If one of these existing tunnel methods can meet the 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 [I-D.ietf-tls-rfc4346-bis] 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. + 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. 4.2.1. TLS Requirements - The tunnel based method MUST support TLS version 1.2 - [I-D.ietf-tls-rfc4346-bis] 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. + 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 4.2.1.1.1. Cipher Suite Negotiation Cipher suite negotiations always suffer from downgrading attacks when they are not secured by any kind of integrity protection. A common practice is a post integrity check in which, as soon as available, the established keys (here the tunnel key) are used to derive integrity keys. These integrity keys are then used by peer and @@ -503,42 +492,44 @@ 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 A tunnel protocol MUST support peer privacy. This requires that the - username is not transmitted in the clear and, if applicable, the peer - certificate is sent confidentially (i.e. encrypted). + username and other attributes associated with the peer are not + transmitted in the clear or to an unauthenticated, unauthorized + party. If applicable, the peer certificate is sent confidentially + (i.e. encrypted). 4.2.1.5. Session Resumption The tunnel method MUST support TLS session resumption as defined in - [I-D.ietf-tls-rfc4346-bis]. The tunnel method MAY support other - methods of session resumption such as those defined in [RFC5077]. + [RFC5246]. The tunnel method MAY support other methods of session + resumption such as those defined in [RFC5077]. 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. EAP Header Protection +4.2.3. Protection of Data External to Tunnel - A tunnel method SHOULD provide protection of the outer EAP header - information when possible to make sure the outer EAP header is not - modified by the intermediaries. + 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 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. @@ -593,65 +584,51 @@ The payload MAY provide a standard attribute format that supports international strings. This attribute format MUST support encoding strings in UTF-8 [RFC3629] format. Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference. 4.4. EAP Channel Binding Requirements - The so-called "lying NAS" problem is a well-documented problem with - the current Extensible Authentication Protocol (EAP) architecture - [RFC3748] when used with pass-through authenticators. Here, a - Network Access Server (NAS), or pass-through authenticator, may - authenticate to the backend AAA infrastructure using one set of - credentials, while representing contrary information to EAP peers. - - Such attacks can be prevented by so-called channel bindings - [I-D.clancy-emu-chbind], in which key channel binding characteristics - are transported from the peer to the server, allowing the server to - verify whether the authenticator has advertised valid information to - the peer. The server can also respond back with additional - information that could be useful for the peer to decide whether or - not to continue its session with the serving authenticator. - - The tunnel method MUST be capable of supporting EAP channel bindings - described above. + The tunnel method MUST be capable of meeting EAP channel binding + requirements described in [I-D.clancy-emu-chbind]. 4.5. Requirements Associated with Carrying Username and Passwords This section describes the requirements associated with tunneled password authentication. The password authentication mentioned here refers to user or machine authentication using a legacy password - database, such as LDAP, OTP, etc. These legacy user databases - typically require the password in its original text form in order to + database or verifier, such as LDAP, OTP, etc. These typically + require the password in its original text form in order to authenticate the peer, hence they require the peer to send the clear text user name and password to the EAP server. 4.5.1. Security Due to the fact that the EAP peer needs to send clear text password - to the EAP server to authenticate to the legacy user database, the - security measures in the following sections MUST be met. + to the EAP server to authenticate against the legacy user + information, the security measures in the following sections MUST be + met. 4.5.1.1. Confidentiality and Integrity 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 user name and password to the server. + clear text password to the server. 4.5.1.3. Server Credential 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 @@ -674,24 +651,27 @@ authentication is for a user or a machine. This allows the EAP server and peer to request and negotiate authentication specifically for a user or machine. This is useful in the case of multiple inner authentications where the user and machine both need to be authenticated. 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 database. + 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. + 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 @@ -705,25 +685,25 @@ cryptographic binding. Without such bindings attacks are feasible on tunnel methods [TUNNEL-MITM] and chained methods. 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 key CTK. In particular, CTK is used to derive 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. + 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. ----------- | TK | MK | ----------- | | v v -------- | CTK | -------- | @@ -746,21 +726,22 @@ 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. + 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 @@ -778,21 +759,21 @@ 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 that affect the ability for a method to achieve these goals. -6.1. Ciphersuite Selection +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. @@ -811,71 +792,60 @@ Mutually anonymous tunnel protocols are prone to man-in-the-middle attacks described in [KHLC07]. During such an attack, an adversary establishes a tunnel with each the peer and the authentication server, while peer and server believe that they established a tunnel with each other. Once both tunnels have been established, the adversary can eavesdrop on all communications within the tunnels, i.e. the execution of the inner authentication method(s). Consequently, the adversary can eavesdrop on the identifiers that are exchanged as part of the EAP method and thus, the privacy of peer and/or authentication server is compromised along with any other data - transmitted within the tunnels. + 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(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. -6.3. Outer EAP Method Header +6.3. Data External to Tunnel - There are several existing EAP methods which use a similar packet - format to EAP-TLS. Often for the initial portions of the exchange - the execution of the method is identical except for the method ID. - Protection of the outer EAP header helps to avoid vulnerabilities - that may arise when an attacker attempts to modify packets to make - one EAP message look like one from a different method. + 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. 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-00 (work in progress), - February 2008. - - [I-D.ietf-eap-keying] - Aboba, B., Simon, D., and P. Eronen, "Extensible - Authentication Protocol (EAP) Key Management Framework", - draft-ietf-eap-keying-22 (work in progress), - November 2007. - - [I-D.ietf-tls-rfc4346-bis] - Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10 - (work in progress), March 2008. + Methods", draft-clancy-emu-chbind-03 (work in progress), + October 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. @@ -889,36 +859,33 @@ Wireless LANs", RFC 4017, March 2005. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007. -7.2. Informative References + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. - [I-D.funk-eap-ttls-v0] - Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS - Authentication Protocol Version 0 (EAP-TTLSv0)", - draft-funk-eap-ttls-v0-05 (work in progress), April 2008. + [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 R. Hurst, "PB-TNC: A Posture + Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", - draft-ietf-nea-pb-tnc-00 (work in progress), April 2008. - - [I-D.ietf-nea-requirements] - Sangster, P., "Network Endpoint Assessment (NEA): Overview - and Requirements", draft-ietf-nea-requirements-07 (work in - progress), April 2008. + draft-ietf-nea-pb-tnc-01 (work in progress), July 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] @@ -948,20 +915,28 @@ [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. + [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. + Tardo, "Network Endpoint Assessment (NEA): Overview and + Requirements", RFC 5209, June 2008. + + [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. Authors' Addresses Katrin Hoeper NIST 100 Bureau Drive, MS: 8930