draft-ietf-emu-eaptunnel-req-01.txt   draft-ietf-emu-eaptunnel-req-02.txt 
EMU Working Group K. Hoeper EMU Working Group K. Hoeper
Internet-Draft NIST Internet-Draft Motorola, Inc.
Intended status: Informational S. Hanna Intended status: Informational S. Hanna
Expires: May 4, 2009 Juniper Networks Expires: August 31, 2009 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 31, 2008 February 27, 2009
Requirements for an Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-01.txt draft-ietf-emu-eaptunnel-req-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 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 Abstract
This memo defines the requirements for a tunnel-based Extensible This memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method. This method will use Transport Authentication Protocol (EAP) Method. This method will use Transport
Layer Security (TLS) to establish a secure tunnel. The tunnel will Layer Security (TLS) to establish a secure tunnel. The tunnel will
provide support for password authentication, EAP authentication and provide support for password authentication, EAP authentication and
the transport of additional data for other purposes. the transport of additional data for other purposes.
Table of Contents 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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 5 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6
3.2. Protect Weak EAP Methods . . . . . . . . . . . . . . . . . 5 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 5 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7
3.5. Emergency Services Authentication . . . . . . . . . . . . 6 3.5. Emergency Services Authentication . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 6 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8
3.7. Resource Constrained Environments . . . . . . . . . . . . 6 3.7. Client Authentication During Tunnel Establishment . . . . 8
3.8. Client Authentication During Tunnel Establishment . . . . 7 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
3.9. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 8
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 7 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 8 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 8 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 9 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 9 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 9 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 9 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
4.2.1.1.3. Tunnel Authentication and Key Establishment . 9 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 13
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 13
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 13
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 4.2.3. Protection of Data External to Tunnel . . . . . . . . 13
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 14
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 4.3.2. Request/Challenge Response Operation . . . . . . . . . 14
4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 14
4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 14
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 14
4.3.6. Internationalization of Display Strings . . . . . . . 13 4.3.6. Internationalization of Display Strings . . . . . . . 15
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 15
4.5. Requirements Associated with Carrying Username and 4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15
4.5.1.3. Server Credential Revocation Checking . . . . . . 14 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 16
4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 16
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16
4.6. Requirements Associated with Carrying EAP Methods . . . . 15 4.6. Requirements Associated with Carrying EAP Methods . . . . 16
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 15 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 15 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with TLS Tunnel . . . . . . . . 15 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 17
4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 18
4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 17 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 19
6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 18 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 20
6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Running EAP methods within a TLS protected tunnel has been deployed Running EAP methods within a TLS protected tunnel has been deployed
in several different solutions. EAP methods supporting this include in several different solutions. EAP methods supporting this include
PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. There have been various PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this has
reasons for employing a protected tunnel for EAP processes. They worked well so there is consensus to continue to use TLS as the basis
include protecting weak authentication exchanges, such as username for a tunnel method. There have been various reasons for employing a
and password. In addition a protected tunnel can provide means to protected tunnel for EAP processes. They include protecting weak
provide peer identity protection and EAP method chaining. Finally, authentication exchanges, such as username and password. In addition
systems have found it useful to transport additional types of data a protected tunnel can provide means to provide peer identity
within the protected tunnel. 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 This document describes the requirements for an EAP tunnel method as
well as for a password protocol supporting legacy password well as for a password protocol supporting legacy password
verification within the tunnel method. verification within the tunnel method.
2. Conventions Used In This Document 2. Conventions Used In This Document
Because this specification is an informational specification (not Because this specification is an informational specification (not
able to directly use [RFC2119]), the following capitalized words are able to directly use [RFC2119]), the following capitalized words are
used to express requirements language used in this specification. used to express requirements language used in this specification.
skipping to change at page 4, line 47 skipping to change at page 5, line 49
MAY - indicates a willingness to allow an optional outcome MAY - indicates a willingness to allow an optional outcome
Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and
"MAY" carry their normal meaning and are not subject to these "MAY" carry their normal meaning and are not subject to these
definitions. definitions.
3. Use Cases 3. Use Cases
To motivate and explain the requirements in this document, a To motivate and explain the requirements in this document, a
representative set of use cases for the EAP tunnel method are representative set of use cases for the EAP tunnel method are
supplied here. The candidate tunnel method is expected to meet all supplied here. The candidate tunnel method is expected to support
of the use cases marked as MUST. all of the use cases marked as MUST.
3.1. Password Authentication 3.1. Password Authentication
Many legacy systems only support user authentication with passwords. Many legacy systems only support user authentication with passwords.
Some of these systems require transport of the actual username and Some of these systems require transport of the actual username and
password to the authentication server. This is true for systems password to the authentication server. This is true for systems
where the authentication server does not have access to the cleartext where the authentication server does not have access to the cleartext
password or a consistent transform of the cleartext password. password or a consistent transform of the cleartext password.
Example of such systems are one time password (OTP) systems and other Example of such systems are one time password (OTP) systems and other
systems where the username and password are submitted to an external 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 However, it MUST NOT expose the username and password to untrusted
parties and it MUST provide protection against man-in-the-middle and 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 Since EAP authentication occurs before network access is granted the
tunnel method SHOULD enable an inner exchange to provide support for tunnel method SHOULD enable an inner exchange to provide support for
minimal password management tasks including password change, "new PIN minimal password management tasks including password change, "new PIN
mode", and "next token mode" required by some systems. 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 Some existing EAP methods have vulnerabilities that could be
eliminated or reduced by running them inside a protected tunnel. For eliminated or reduced by running them inside a protected tunnel. For
example, a method such as EAP-MD5 does not provide mutual example, a method such as EAP-MD5 does not provide mutual
authentication or protection from dictionary attacks. In addition, authentication or protection from dictionary attacks. Without extra
tunneled EAP methods are subject to a specific form of man-in-the- protection, tunnel-based EAP methods are vulnerable to a special type
middle attack described in [TUNNEL-MITM]. 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 The tunnel method MUST support protection of weak EAP methods,
protect against man-in-the-middle attacks associated with tunneled including cryptographic protection from tunnel MitM attacks. In
authentication. combination with an appropriate security policy this will thwart MitM
attacks against inner methods.
3.3. Chained EAP Methods 3.3. Chained EAP Methods
Several circumstances are best addressed by using chained EAP Several circumstances are best addressed by using chained EAP
methods. For example, it may be desirable to authenticate the user methods. For example, it may be desirable to authenticate the user
and also authenticate the device that he or she is using. However, and also authenticate the device that he or she is using. However,
chained EAP methods from different conversations can be re-directed chained EAP methods from different conversations can be re-directed
into the same conversation by an attacker giving the authenticator into the same conversation by an attacker giving the authenticator
the impression that both conversations terminate at the same end- the impression that both conversations terminate at the same end-
point. Cryptographic binding can be used to bind the results of key point. Cryptographic binding can be used to bind the results of key
skipping to change at page 6, line 32 skipping to change at page 7, line 46
user to be able to gain access to the network to make an emergency 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 telephone call. To avoid eavesdropping on this call, it's best to
negotiate link layer security as with any other authentication. negotiate link layer security as with any other authentication.
Therefore, the tunnel method SHOULD allow anonymous peers or server- Therefore, the tunnel method SHOULD allow anonymous peers or server-
only authentication, but still derive keys that can be used for link only authentication, but still derive keys that can be used for link
layer security. The tunnel method MAY also allow for the bypass of layer security. The tunnel method MAY also allow for the bypass of
server authentication processing on the client. Forgoing server authentication processing on the client. Forgoing
authentication increases the chance of man-in-the-middle and other authentication increases the chance of man-in-the-middle and other
types of attacks that can compromise the derived keys used for link 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 3.6. Network Endpoint Assessment
The Network Endpoint Assessment (NEA) protocols and reference model The Network Endpoint Assessment (NEA) protocols and reference model
described in [RFC5209] provide a standard way to check the health described in [RFC5209] provide a standard way to check the health
("posture") of a device at or after the time it connects to a ("posture") of a device at or after the time it connects to a
network. If the device does not comply with the network's network. If the device does not comply with the network's
requirements, it can be denied access to the network or granted requirements, it can be denied access to the network or granted
limited access to remediate itself. EAP is a convenient place for limited access to remediate itself. EAP is a convenient place for
conducting an NEA exchange. conducting an NEA exchange.
The tunnel method SHOULD support carrying NEA protocols such as PB- 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 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, these protocols may be required to be carried in an EAP
method. method.
3.7. Resource Constrained Environments 3.7. Client Authentication During Tunnel Establishment
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
In cases where client authentication can be performed as part of the In cases where client authentication can be performed as part of the
tunnel establishment it is efficient for the tunnel method to allow 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. authentication during tunnel establishment.
3.9. Extensibility 3.8. Extensibility
The tunnel method MUST provide extensibility so that additional types The tunnel method MUST provide extensibility so that additional types
of data can be carried inside the tunnel in the future. This removes of data can be carried inside the tunnel in the future. This removes
the need to develop new tunneling methods for specific purposes. the need to develop new tunneling methods for specific purposes.
One example of a application for extensibility is credential One example of a application for extensibility is credential
provisioning. When a peer has authenticated with EAP, this is a provisioning. When a peer has authenticated with EAP, this is a
convenient time to distribute credentials to that peer that may be convenient time to distribute credentials to that peer that may be
used for later authentication exchanges. For example, the used for later authentication exchanges. For example, the
authentication server can provide a private key or shared key to 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 peer that can be used by the peer to perform rapid re-authentication
or roaming. In addition there have been proposals to perform 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. Requirements
4.1. General Requirements 4.1. General Requirements
4.1.1. RFC Compliance 4.1.1. RFC Compliance
The tunnel method MUST include a Security Claims section with all The tunnel method MUST include a Security Claims section with all
security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In 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 addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC
skipping to change at page 8, line 50 skipping to change at page 10, line 7
requirements contained in this specification then that method SHOULD requirements contained in this specification then that method SHOULD
be preferred over a new method. be preferred over a new method.
Even if minor modifications or extensions to an existing tunnel Even if minor modifications or extensions to an existing tunnel
method are needed, this method SHOULD be preferred over a completely method are needed, this method SHOULD be preferred over a completely
new method so that the advantage of accumulated deployment experience new method so that the advantage of accumulated deployment experience
and security analysis can be gained. and security analysis can be gained.
4.2. Tunnel Requirements 4.2. Tunnel Requirements
Existing tunnel methods make use of TLS [RFC5246] to provide the The following section discusses requirements for TLS Tunnel
protected tunnel. In general this has worked well so there is Establishment.
consensus to continue to use TLS as the basis for a tunnel method.
4.2.1. TLS Requirements 4.2.1. TLS Requirements
The tunnel based method MUST support TLS version 1.2 [RFC5246] and 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 SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to
enable the possibility of backwards compatibility with existing enable the possibility of backwards compatibility with existing
deployments. The following section discusses requirements for TLS deployments. The following section discusses requirements for TLS
Tunnel Establishment. Tunnel Establishment.
4.2.1.1. Cipher Suites 4.2.1.1. Cipher Suites
skipping to change at page 11, line 4 skipping to change at page 12, line 10
o Key freshness, i.e. EAP peer and EAP server are assured that the 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 derived keys are fresh and the re-use of expired key material is
prevented. The freshness property is typically achieved by using prevented. The freshness property is typically achieved by using
one or more of the following techniques: nonces, sequence numbers, one or more of the following techniques: nonces, sequence numbers,
timestamps. timestamps.
The mandatory to implement cipher suites MUST NOT include "export The mandatory to implement cipher suites MUST NOT include "export
strength" cipher suites, cipher suites providing mutually anonymous strength" cipher suites, cipher suites providing mutually anonymous
authentication or static Diffie-Hellman cipher suites. NIST authentication or static Diffie-Hellman cipher suites. NIST
publication [NIST SP 800-52] can be consulted for a list of publication [NIST SP 800-57p3] can be consulted for a list of
acceptable TLS v1.0 cipher suites and [NIST SP 800-108] for acceptable TLS v1.0, v1.1 and v 1.2 cipher suites and NIST
additional information on secure key derivation. publication [NIST SP 800-108] for additional information on secure
key derivation.
In addition a tunnel method SHOULD provide cipher suites to meet the In addition a tunnel method SHOULD provide cipher suites to meet the
following additional recommendations for good key establishment following additional recommendations for good key establishment
algorithms: algorithms:
o Key control , i.e., EAP peer and authentication server each o Key control , i.e., EAP peer and authentication server each
contribute to the key computation of the tunnel key. This contribute to the key computation of the tunnel key. This
property prevents that a single protocol participant controls the property prevents that a single protocol participant controls the
value of an established key. In that way, protocol participants value of an established key. In that way, protocol participants
can ensure that generated keys are fresh and have good random can ensure that generated keys are fresh and have good random
skipping to change at page 12, line 29 skipping to change at page 13, line 36
4.2.2. Fragmentation 4.2.2. Fragmentation
Tunnel establishment sometimes requires the exchange of information Tunnel establishment sometimes requires the exchange of information
that exceeds what can be carried in a single EAP message. In that exceeds what can be carried in a single EAP message. In
addition information carried within the tunnel may also exceed this addition information carried within the tunnel may also exceed this
limit. Therefore a tunnel method MUST support fragmentation and limit. Therefore a tunnel method MUST support fragmentation and
reassembly. reassembly.
4.2.3. Protection of Data External to Tunnel 4.2.3. Protection of Data External to Tunnel
A tunnel method MUST provide protection of any data external to the An attacker in the middle can modify clear text values such as
TLS tunnel that can cause a problem if it is modified by an attacker. protocol version and type code information communicated outside the
This may include data such as type codes and version numbers 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 4.3. Tunnel Payload Requirements
This section describes the payload requirements inside the tunnel. This section describes the payload requirements inside the tunnel.
These requirements frequently express features that a candidate These requirements frequently express features that a candidate
protocol must be capable of offering so that a deployer can decide protocol must be capable of offering so that a deployer can decide
whether to make use of that feature. This section does not state whether to make use of that feature. This section does not state
requirements about what features of each protocol must be used during requirements about what features of each protocol must be used during
a deployment. a deployment.
skipping to change at page 14, line 39 skipping to change at page 15, line 48
The clear text password exchange MUST be integrity and The clear text password exchange MUST be integrity and
confidentiality protected. As long as the password exchange occurs confidentiality protected. As long as the password exchange occurs
inside an authenticated and encrypted tunnel, this requirement is inside an authenticated and encrypted tunnel, this requirement is
met. met.
4.5.1.2. Authentication of Server 4.5.1.2. Authentication of Server
The EAP server MUST be authenticated before the peer can send the The EAP server MUST be authenticated before the peer can send the
clear text password to the server. 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 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 server before it has network access to check the revocation status of
the server's credentials. Therefore, the tunnel method MUST support the server's credentials. Therefore, the tunnel method MUST support
mechanisms to check the revocation status of a credential. The mechanisms to check the revocation status of a credential. The
tunnel method SHOULD make use of Online Certificate Status Protocol tunnel method SHOULD make use of Online Certificate Status Protocol
(OCSP) [RFC2560] or Server-based Certificate Validation Protocol (OCSP) [RFC2560] or Server-based Certificate Validation Protocol
(SCVP) [RFC5055] to obtain the revocation status of the EAP server (SCVP) [RFC5055] to obtain the revocation status of the EAP server
certificate. certificate.
skipping to change at page 15, line 34 skipping to change at page 16, line 39
4.5.4. Password Change 4.5.4. Password Change
The password authentication exchange MUST support password change, as The password authentication exchange MUST support password change, as
well as other multiple round trips exchanges like new pin mode and well as other multiple round trips exchanges like new pin mode and
next token mode for OTP verifiers. next token mode for OTP verifiers.
4.6. Requirements Associated with Carrying EAP Methods 4.6. Requirements Associated with Carrying EAP Methods
The tunnel method MUST be able to carry inner EAP methods without 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 4.6.1. Method Negotiation
The tunnel method MUST support the protected negotiation of the inner The tunnel method MUST support the protected negotiation of the inner
EAP method. It MUST NOT allow the inner EAP method negotiation to be EAP method. It MUST NOT allow the inner EAP method negotiation to be
downgraded or manipulated by intermediaries. downgraded or manipulated by intermediaries.
4.6.2. Chained Methods 4.6.2. Chained Methods
The tunnel method MUST support the chaining of multiple EAP methods. The tunnel method MUST support the chaining of multiple EAP methods.
The tunnel method MUST allow for the communication of intermediate The tunnel method MUST allow for the communication of intermediate
result and verification of compound binding between executed inner result and verification of compound binding between executed inner
methods when chained methods are employed. 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 The tunnel method MUST provide a mechanism to bind the tunnel
protocol and the inner EAP method. This property is referred to as protocol and the inner EAP method. This property is referred to as
cryptographic binding. Without such bindings attacks are feasible on cryptographic binding. Such bindings are an important tool for
tunnel methods [TUNNEL-MITM] and chained methods. 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 Cryptographic bindings are typically achieved by securely mixing the
established keying material (say tunnel key TK) from the tunnel established keying material (say tunnel key TK) from the tunnel
protocol with the established keying material (say method key MK) protocol with the established keying material (say method key MK)
from the inner authentication method(s) in order to derive fresh from the inner authentication method(s) in order to derive fresh
keying material. If chained EAP methods are executed in the tunnel, keying material. If chained EAP methods are executed in the tunnel,
all derived inner keys are combined to one method key MK. The keying all derived inner keys are combined with the tunnel key to create a
material derived from mixing tunnel and method keys is also referred new compound tunnel key (CTK). In particular, CTK is used to derive
to as compound tunnel key (CTK). In particular, CTK is used to the EAP MSK, EMSK and other transient keys (TEK), such as transient
derive the EAP MSK, EMSK and other transient keys (TEK), such as encryption keys and integrity protection keys. The key hierarchy for
transient encryption keys and integrity protection keys. The key tunnel methods executions that derive compound keys for the purpose
hierarchy for tunnel methods executions that derive compound keys for of cryptographic binding is depicted in Figure 1.
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 | | TK | MK |
----------- -----------
| | | |
v v v v
-------- --------
| CTK | | CTK |
-------- --------
| |
v v
---------------- ----------------
| | | | | |
v v v v v v
------- ------ ------- ------- ------ -------
| TEK | | MSK | | EMSK | | TEK | | MSK | | EMSK |
------- ------- -------- ------- ------- --------
Figure 1: Compound Keys Figure 1: Compound Keys
For every key deriving inner EAP method that completes successfully Furthermore, all compound keys CTK_i and all keys derived from it
within the tunnel cryptographic binding MUST be performed similar to SHOULD be derived in accordance to the guidelines for key derivations
the following: and key hierarchies as specified in Section 4.2.1.1.3. In
particular, all derived keys MUST have a lifetime assigned that does
o compute a compound key CTK using the keying material from tunnel not exceed the lifetime of any key higher in the key hierarchy, and
protocol and all tunneled inner authentication method(s) as inputs MUST prevent domino effects where a compromise in one part of the
system leads to compromises in other parts of the system.
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.
4.6.4. Peer Initiated 4.6.4. Peer Initiated
The tunnel method SHOULD allow for the peer to initiate an inner EAP The tunnel method SHOULD allow for the peer to initiate an inner EAP
authentication in order to meet its policy requirements for authentication in order to meet its policy requirements for
authenticating the server. authenticating the server.
4.6.5. Method Meta-data 4.6.5. Method Meta-data
The tunnel method MUST allow for the communication of additional data The tunnel method MUST allow for the communication of additional data
skipping to change at page 18, line 36 skipping to change at page 20, line 10
and/or authentication server is compromised along with any other data and/or authentication server is compromised along with any other data
transmitted within the tunnels. This document requires server transmitted within the tunnels. This document requires server
authentication to avoid the risks associated with anonymous cipher authentication to avoid the risks associated with anonymous cipher
suites. suites.
6.2. Tunneled Authentication 6.2. Tunneled Authentication
In many cases a tunnel method provides mutual authentication by In many cases a tunnel method provides mutual authentication by
authenticating the server during tunnel establishment and authenticating the server during tunnel establishment and
authenticating the peer within the tunnel using an EAP method. As authenticating the peer within the tunnel using an EAP method. As
described in [TUNNEL-MITM], this mode of operation can allow a man- described in [TUNNEL-MITM], this mode of operation can allow tunnel
in-the-middle to authenticate to the server as the peer by tunneling man-in-the-middle attackers to authenticate to the server as the peer
the inner EAP protocol messages to and from a peer executing the by tunneling the inner EAP protocol messages to and from a peer
method outside a tunnel or with an untrustworthy server. executing the method outside a tunnel or with an untrustworthy
Cryptographic binding between the established keying material from server. Cryptographic binding between the established keying
the inner authentication method(s) and the tunnel protocol verifies material from the inner authentication method(s) and the tunnel
that the endpoints of the tunnel and the inner authentication protocol verifies that the endpoints of the tunnel and the inner
method(s) are the same. This can thwart the attack if the inner authentication method(s) are the same. This can thwart the attack if
method derived keys of sufficient strength that they cannot be broken the inner method derived keys of sufficient strength that they cannot
in real-time. be broken in real-time.
In cases where the inner authentication method does not generate any 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 or only weak key material, security policies must be enforced such
does not execute the inner method with the same credentials outside a that the peer cannot execute the inner method with the same
protective tunnel or with an untrustworthy server. credentials outside a protective tunnel or with an untrustworthy
server.
6.3. Data External to Tunnel 6.3. Data External to Tunnel
The tunnel method will use data that is outside the TLS tunnel such 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 as the EAP type code or version numbers. If an attacker can
compromise the protocol by modifying these values the tunnel method compromise the protocol by modifying these values the tunnel method
MUST protect this data. MUST protect this data from modification.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.clancy-emu-chbind] [I-D.clancy-emu-chbind]
Clancy, C. and K. Hoeper, "Channel Binding Support for EAP Clancy, C. and K. Hoeper, "Channel Binding Support for EAP
Methods", draft-clancy-emu-chbind-03 (work in progress), Methods", draft-clancy-emu-chbind-04 (work in progress),
October 2008. November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
skipping to change at page 20, line 11 skipping to change at page 21, line 33
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008. RFC 5247, August 2008.
7.2. Informative References 7.2. Informative References
[I-D.ietf-nea-pb-tnc] [I-D.ietf-nea-pb-tnc]
Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC", 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] [I-D.mahy-eap-enrollment]
Mahy, R., "An Extensible Authentication Protocol (EAP) Mahy, R., "An Extensible Authentication Protocol (EAP)
Enrollment Method", draft-mahy-eap-enrollment-01 (work in Enrollment Method", draft-mahy-eap-enrollment-01 (work in
progress), March 2006. progress), March 2006.
[KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail",
ICST QShine , August 2007. ICST QShine , August 2007.
[NIST SP 800-108] [NIST SP 800-108]
Chen, L., "Recommendation for Key Derivation Using Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions", Draft NIST Special Pseudorandom Functions", Draft NIST Special
Publication 800-108, April 2008. Publication 800-108, April 2008.
[NIST SP 800-52] [NIST SP 800-120]
Chernick, C., Edington III, C., Fanto, M., and R. Hoeper, K. and L. Chen, "Recommendation for EAP Methods
Rosenthal, "Guidelines for the Selection and Use of Used in Wireless Network Access Authentication", Draft
Transport Layer Security (TLS) Implementations", NIST NIST Special Publication 800-120, December 2008.
Special Publication 800-52, June 2005.
[NIST SP 800-57] [NIST SP 800-57]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendation for Key Management - Part 1: General "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", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
skipping to change at page 21, line 20 skipping to change at page 22, line 48
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[TUNNEL-MITM] [TUNNEL-MITM]
Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunnelled Authentication Protocols", Cryptology ePrint in Tunnelled Authentication Protocols", Cryptology ePrint
Archive: Report 2002/163, November 2002. 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 Authors' Addresses
Katrin Hoeper Katrin Hoeper
NIST Motorola, Inc.
100 Bureau Drive, MS: 8930 1301 E Algonquin Rd
Gaithersburg, MD 20899 Schaumburg, IL 60196
USA USA
Email: khoeper@nist.gov Email: khoeper@motorola.com
Stephen Hanna Stephen Hanna
Juniper Networks Juniper Networks
3 Beverly Road 3 Beverly Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: shanna@juniper.net Email: shanna@juniper.net
Hao Zhou Hao Zhou
skipping to change at page 23, line 4 skipping to change at line 1026
USA USA
Email: hzhou@cisco.com Email: hzhou@cisco.com
Joseph Salowey (editor) Joseph Salowey (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
2901 3rd. Ave 2901 3rd. Ave
Seattle, WA 98121 Seattle, WA 98121
USA USA
Email: jsalowey@cisco.com 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).
 End of changes. 49 change blocks. 
177 lines changed or deleted 233 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/