draft-ietf-emu-eaptunnel-req-04.txt   draft-ietf-emu-eaptunnel-req-05.txt 
EMU Working Group K. Hoeper EMU Working Group K. Hoeper
Internet-Draft Motorola, Inc. Internet-Draft Motorola, Inc.
Intended status: Informational S. Hanna Intended status: Informational S. Hanna
Expires: April 10, 2010 Juniper Networks Expires: September 9, 2010 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 7, 2009 March 8, 2010
Requirements for a Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-04.txt draft-ietf-emu-eaptunnel-req-05.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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering 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 April 10, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This memo defines the requirements for a tunnel-based Extensible This document may contain material from IETF Documents or IETF
Authentication Protocol (EAP) Method. This method will use Transport Contributions published or made publicly available before November
Layer Security (TLS) to establish a secure tunnel. The tunnel will 10, 2008. The person(s) controlling the copyright in some of this
provide support for password authentication, EAP authentication and material may not have granted the IETF Trust the right to allow
the transport of additional data for other purposes. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used In This Document . . . . . . . . . . . . . . 5 2. Conventions Used In This Document . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6
skipping to change at page 3, line 29 skipping to change at page 3, line 29
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 11 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 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 . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Protection of Data External to Tunnel . . . . . . . . 12 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 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.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13
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 . . . . . . . 14 4.3.6. Internationalization of Display Strings . . . . . . . 14
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and 4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
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 Certificate Revocation Checking . . . . . . 15 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
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 . . . . 16 4.6. Requirements Associated with Carrying EAP Methods . . . . 16
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20
6.4. Separation of TLS Tunnel and Inner Authentication 6.4. Separation of TLS Tunnel and Inner Authentication
Termination . . . . . . . . . . . . . . . . . . . . . . . 19 Termination . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 23
Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23
Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23 Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this
has worked well so there is consensus to continue to use TLS as the has worked well so there is consensus to continue to use TLS as the
basis for a tunnel method. There have been various reasons for basis for a tunnel method. There have been various reasons for
employing a protected tunnel for EAP processes. They include employing a protected tunnel for EAP processes. They include
protecting weak authentication exchanges, such as username and protecting weak authentication exchanges, such as username and
skipping to change at page 5, line 46 skipping to change at page 5, line 46
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 support supplied here. The candidate tunnel method needs to support all of
all of the use cases marked as MUST. the use cases that are marked below 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 support transporting party for validation. The tunnel method MUST support transporting
username and password to the authentication server. However, it MUST cleartext username and password to the EAP server. It MUST NOT
NOT expose the username and password to parties in the communication reveal information about the username and password to parties in the
path between the peer and the EAP Server and it MUST provide communication path between the peer and the EAP Server. The
protection against man-in-the-middle and dictionary attacks. The advantage any attacker gains against the tunneled method when
combination of the tunnel authentication and password authentication employing a username and password for authentication MUST be through
MUST enable mutual authentication. interaction and not computation. The tunnel MUST provide protection
from man-in-the-middle 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. Protection of 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 EAP-MD5 does not provide mutual authentication or
authentication or protection from dictionary attacks. Without extra protection from dictionary attacks. Without extra protection,
protection, tunnel-based EAP methods are vulnerable to a special type tunnel-based EAP methods are vulnerable to a special type of tunnel
of tunnel man-in-the-middle attack [TUNNEL-MITM]. This attack is man-in-the-middle attack [TUNNEL-MITM]. This attack is referred to
referred to as "tunnel MitM attack" in the remainder of this as "tunnel MitM attack" in the remainder of this document. The
document. The additional protection needed to thwart tunnel MitM additional protection needed to thwart tunnel MitM attacks depends on
attacks depends on the inner method executed within the tunnel. In the inner method executed within the tunnel. When weak methods are
particular, when weak methods are used, security policies enforcing used, these attacks can be mitigated via security policies that
that such methods can only be executed inside a tunnel but never require the method to be used only within a tunnel. On the other
outside one are required to mitigate the attack. On the other hand, hand, a technical solution (so-called cryptographic bindings) can be
a technical solution (so-called cryptographic bindings) can be used used whenever the inner method derives key material and is not
whenever the inner method is not susceptible to attacks outside a susceptible to attacks outside a tunnel. Only the latter mitigation
tunnel and derives keying material. Only the latter mitigation
technique can be made an actual requirement for tunnel-based EAP technique can be made an actual requirement for tunnel-based EAP
methods (see Section 4.6.3), while security policies are outside the methods (see Section 4.6.3), while security policies are outside the
scope of this requirement draft. Please refer to the NIST scope of this requirement draft. Please refer to the NIST
Recommendation for EAP Methods Used in Wireless Network Access Recommendation for EAP Methods Used in Wireless Network Access
Authentication [NIST SP 800-120] for a discussion on security Authentication [NIST SP 800-120] for a discussion on security
policies and complete solutions for thwarting tunnel MitM attacks. policies and complete solutions for thwarting tunnel MitM attacks.
The tunnel method MUST support protection of weak EAP methods. The tunnel method MUST support protection of weak EAP methods.
Cryptographic protection from tunnel MitM attacks MUST be provided Cryptographic protection from tunnel MitM attacks MUST be provided
for all key generating methods. In combination with an appropriate for all key generating methods. In combination with an appropriate
security policy this will thwart MitM attacks against inner methods. 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 being used. However, chained EAP
chained EAP methods from different conversations can be re-directed methods from different conversations can be re-directed into the same
into the same conversation by an attacker giving the authenticator conversation by an attacker giving the authenticator the impression
the impression that both conversations terminate at the same end- that both conversations terminate at the same end-point.
point. Cryptographic binding can be used to bind the results of key Cryptographic binding can be used to bind the results of chained key
generating methods together or to an encompassing tunnel. generating methods together or to an encompassing tunnel.
The tunnel method MUST support chained EAP methods while including The tunnel method MUST support chained EAP methods while including
strong protection against attacks on method chaining. strong protection against attacks on method chaining.
3.4. Identity Protection 3.4. Identity Protection
When performing an EAP authentication, the peer may want to protect When performing an EAP authentication, the peer may want to protect
its identity, only disclosing its identity to a trusted backend its identity and only disclose it to a trusted EAP server. This
authentication server. This helps to maintain the privacy of the helps to maintain peer privacy.
peer's identity.
The tunnel method MUST support identity protection, ensuring that The tunnel method MUST support identity protection, therefore the
peer identity is not disclosed to the authenticator and any other identity of the peer used for authentication purposes MUST NOT be
intermediaries before the server that terminates the tunnel method. obtainable by any entity other than the EAP server terminating the
Peer identity protection provided by the tunnel method applies to tunnel method. Peer identity protection provided by the tunnel
tunnel method and inner method specific identities. Note that the method applies to tunnel method and inner method specific identities.
peer may need to expose the realm portion of the EAP outer identity Note that the peer may need to expose the realm portion of the EAP
in the NAI [RFC4282] in a roaming scenario in order to reach the outer identity in the NAI [RFC4282] in a roaming scenario in order to
appropriate authentication server. reach the appropriate authentication server.
3.5. Anonymous Service Access 3.5. Anonymous Service Access
When network service is provided, it is sometimes desirable for any When network service is provided, it is sometimes desirable for a
user to be able to gain access to the network to enable access to user to gain network access in order to access limited services for
limited services emergency communication or troubleshooting emergency communication or troubleshooting information. To avoid
information. To avoid eavesdropping, it's best to negotiate link eavesdropping, it's best to negotiate link layer security as with any
layer security as with any other authentication. 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, while still deriving keys that can be used for
layer security. The tunnel method MAY also allow for the bypass of link layer security. The tunnel method MAY also allow for the bypass
server authentication processing on the client. Forgoing of server authentication processing on the client.
authentication increases the chance of man-in-the-middle and other
types of attacks that can compromise the derived keys used for link Forgoing user or server authentication increases the chance of man-
layer security. In addition, passwords and other sensitive in-the-middle and other types of attacks that can compromise the
information must not be disclosed to an unauthenticated or derived keys used for link layer security. Therefore, passwords and
unauthorized server. other sensitive information MUST NOT be disclosed to an
unauthenticated server, or to a server that is not authorized to
authenticate the user.
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. Client Authentication During Tunnel Establishment 3.7. Client Authentication During Tunnel Establishment
In some cases the peer will have credentials usable to authenticate In some cases the peer will have credentials that allow it to
during tunnel establishment. These credentials may only partially authenticate during tunnel establishment. These credentials may only
authenticate the identity of the peer and additional authentication partially authenticate the identity of the peer and additional
may be required inside the tunnel. If the identity of the peer is authentication may be required inside the tunnel. For example, a
fully authenticated during tunnel establishment then the tunnel may communication device may be authenticated during tunnel
be used to communicate additional data. The tunnel method MUST be establishment, in addition user authentication may be required to
capable of providing client side authentication during tunnel satisfy authentication policy. The tunnel method MUST be capable of
establishment. providing client side authentication during tunnel establishment.
3.8. Extensibility 3.8. Extensibility
The tunnel method MUST provide extensibility so that additional data The tunnel method MUST provide extensibility so that additional data
related to authentication, authorization and network access can be related to authentication, authorization and network access can be
carried inside the tunnel in the future. This removes the need to carried inside the tunnel in the future. This removes the need to
develop new tunneling methods for specific purposes. develop new tunneling methods for specific purposes.
One example of a application for extensibility is credential An application for extensibility is credential provisioning. When a
provisioning. When a peer has authenticated with EAP, this is a peer has authenticated with EAP, this is a convenient time to
convenient time to distribute credentials to that peer that may be distribute credentials to that peer that may be used for later
used for later authentication exchanges. For example, the authentication exchanges. For example, the authentication server can
authentication server can provide a private key or shared key to the provide a private key or shared key to the peer that can be used by
peer that can be used by the peer to perform rapid re-authentication the peer to perform rapid re-authentication or roaming. In addition
or roaming. In addition there have been proposals to perform there have been proposals to perform enrollment within EAP, such as
enrollment within EAP, such as [I-D.mahy-eap-enrollment]. Another [I-D.mahy-eap-enrollment]. Another use for extensibility is support
use for extensibility is support for authentication frameworks other for alternate authentication frameworks within the tunnel.
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 9, line 26 skipping to change at page 9, line 26
protection as specified in Section 7.3 in RFC 3748. protection as specified in Section 7.3 in RFC 3748.
The tunnel method MUST be unconditionally compliant with RFC 4017 The tunnel method MUST be unconditionally compliant with RFC 4017
[RFC4017] (using the definition of "unconditionally compliant" [RFC4017] (using the definition of "unconditionally compliant"
contained in section 1.1 of RFC 4017). This means that the method contained in section 1.1 of RFC 4017). This means that the method
MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT
requirements in RFC 4017. requirements in RFC 4017.
The tunnel method MUST meet all the MUST and SHOULD requirements The tunnel method MUST meet all the MUST and SHOULD requirements
relevant to EAP methods contained in the EAP Key Management Framework relevant to EAP methods contained in the EAP Key Management Framework
[RFC5247] or its successor. This includes the generation of the MSK, [RFC5247] or any successor. This includes the generation of the MSK,
EMSK, Peer-Id, Server-Id and Session-Id. This will enable the tunnel EMSK, Peer-Id, Server-Id and Session-Id. These requirements will
method to properly fit into the EAP key management framework, enable the tunnel method to properly fit into the EAP key management
maintaining all of the security properties and guarantees of that framework, maintaining all of the security properties and guarantees
framework. of that framework.
The tunnel method MUST NOT be tied to any single cryptographic The tunnel method MUST NOT be tied to any single cryptographic
algorithm. Instead, it MUST support run-time negotiation to select algorithm. Instead, it MUST support run-time negotiation to select
among an extensible set of cryptographic algorithms. This includes among an extensible set of cryptographic algorithms, such as
algorithms used with certificates presented during tunnel algorithms used with certificates presented during tunnel
establishment. This "cryptographic algorithm agility" provides establishment. This "cryptographic algorithm agility" provides
several advantages. Most important, when a weakness in an algorithm several advantages. Most important, when a weakness in an algorithm
is discovered or increased processing power overtakes an algorithm, is discovered or increased processing power overtakes an algorithm,
users can easily transition to a new algorithm. Also, users can users can easily transition to a new algorithm. Also, users can
choose the algorithm that best meets their needs. choose the algorithm that best meets their needs.
The tunnel method MUST meet the SHOULD and MUST requirements The tunnel method MUST meet the SHOULD and MUST requirements
pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962].
This includes: cryptographic algorithm independence; strong, fresh This includes: cryptographic algorithm independence; strong, fresh
skipping to change at page 10, line 23 skipping to change at page 10, line 23
4.2. Tunnel Requirements 4.2. Tunnel Requirements
The following section discusses requirements for TLS Tunnel The following section discusses requirements for TLS Tunnel
Establishment. Establishment.
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
may support earlier versions to enable the possibility of backwards may support earlier versions to enable the possibility of backwards
compatibility. The following section discusses requirements for TLS compatibility.
Tunnel Establishment.
4.2.1.1. Cipher Suites 4.2.1.1. Cipher Suites
4.2.1.1.1. Cipher Suite Negotiation 4.2.1.1.1. Cipher Suite Negotiation
Cipher suite negotiations always suffer from downgrading attacks when Cipher suite negotiations always suffer from downgrading attacks when
they are not secured by any kind of integrity protection. A common they are not secured by any kind of integrity protection. A common
practice is a post integrity check in which, as soon as available, practice is a post integrity check in which, as soon as available,
the established keys (here the tunnel key) are used to derive the established keys (here the tunnel key) are used to derive
integrity keys. These integrity keys are then used by peer and integrity keys. These integrity keys are then used by peer and
authentication server to verify whether the cipher suite negotiation authentication server to verify whether the cipher suite negotiation
has been maliciously altered by another party. has been maliciously altered by another party.
Integrity checks prevent downgrading attacks only if the derived Integrity checks prevent downgrading attacks only if the derived
integrity keys and the employed integrity algorithms cannot be broken integrity keys and the employed integrity algorithms cannot be broken
in real-time. See Section 6.1 or [KHLC07] for more information on in real-time. See Section 6.1 or [KHLC07] for more information on
this. Hence, the tunnel method MUST provide integrity protected this. Hence, the tunnel method MUST provide integrity protected
cipher suite negotiation with secure integrity algorithms and cipher suite negotiation with secure integrity algorithms and
integrity keys. integrity keys.
All versions of TLS meet these requirements as long as the cipher TLS provides protected cipher suite negotiation as long as all the
suites used provide strong authentication, key establishment and data cipher suites supported provide strong authentication, key
integrity protection. establishment and data integrity protection.
4.2.1.1.2. Tunnel Data Protection Algorithms 4.2.1.1.2. Tunnel Data Protection Algorithms
In order to prevent attacks on the cryptographic algorithms employed In order to prevent attacks on the cryptographic algorithms employed
by inner authentication methods, a tunnel protocol's protection needs by inner authentication methods, a tunnel protocol's protection needs
to provide a basic level of algorithm strength. The tunnel method to provide a basic level of algorithm strength. The tunnel method
MUST provide at least one mandatory to implement cipher suite that MUST provide at least one mandatory to implement cipher suite that
provides the equivalent security of 128-bit AES for encryption and provides the equivalent security of 128-bit AES for encryption and
message authentication. See Part 1 of the NIST Recommendation for message authentication. See Part 1 of the NIST Recommendation for
Key Management [NIST SP 800-57] for a discussion of the relative Key Management [NIST SP 800-57] for a discussion of the relative
skipping to change at page 11, line 46 skipping to change at page 11, line 41
requirements for tunnel protocols in NIST DRAFT Recommendation for requirements for tunnel protocols in NIST DRAFT Recommendation for
EAP Methods Used in Wireless Network Access Authentication [NIST SP EAP Methods Used in Wireless Network Access Authentication [NIST SP
800-120]. 800-120].
4.2.1.2. Tunnel Replay Protection 4.2.1.2. Tunnel Replay Protection
In order to prevent replay attacks on a tunnel protocol, the message In order to prevent replay attacks on a tunnel protocol, the message
authentication MUST be generated using a time-variant input such as authentication MUST be generated using a time-variant input such as
timestamps, sequence numbers, nonces, or a combination of these so timestamps, sequence numbers, nonces, or a combination of these so
that any re-use of the authentication data can be detected as that any re-use of the authentication data can be detected as
invalid. TLS makes use of an 8 byte sequence number to protect invalid. TLS provides sufficient replay protection to meet this
against replay. requirements as long as strong ciphersuites are used.
4.2.1.3. TLS Extensions 4.2.1.3. TLS Extensions
In order to meet the requirements in this document TLS extensions MAY In order to meet the requirements in this document TLS extensions MAY
be used. For example, TLS extensions may be useful in providing be used. For example, TLS extensions may be useful in providing
certificate revocation information via the TLS OCSP extension (thus certificate revocation information via the TLS OCSP extension (thus
meeting the requirement in Section 4.5.1.3). meeting the requirement in Section 4.5.1.3).
4.2.1.4. Peer Identity Privacy 4.2.1.4. Peer Identity Privacy
A tunnel protocol MUST support peer privacy. This requires that the A tunnel protocol MUST support peer privacy. This requires that the
username and other attributes associated with the peer are not username and other attributes associated with the peer are not
transmitted in the clear or to an unauthenticated, unauthorized transmitted in the clear or to an unauthenticated, unauthorized
party. Peer identity protection provided by the tunnel method party. Peer identity protection provided by the tunnel method
applies to tunnel methods and inner method specific identities. If applies to establishment of the tunnel and protection of inner method
applicable, the peer certificate is sent confidentially (i.e. specific identities. If applicable, the peer certificate is sent
encrypted). confidentially (i.e. encrypted).
4.2.1.5. Session Resumption 4.2.1.5. Session Resumption
The tunnel method MUST support TLS session resumption as defined in The tunnel method MUST support TLS session resumption as defined in
[RFC5246]. The tunnel method MAY support other methods of session [RFC5246]. The tunnel method MAY support other methods of session
resumption such as those defined in [RFC5077]. resumption such as those defined in [RFC5077].
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
An attacker in the middle can modify clear text values such as A man-in-the-middle attacker can modify clear text values such as
protocol version and type code information communicated outside the protocol version and type code information communicated outside the
TLS tunnel. The tunnel method MUST provide implicit or explicit TLS tunnel. The tunnel method MUST provide implicit or explicit
protection of the protocol version and type code. If modification of protection of the protocol version and type code. If modification of
other information external to the tunnel can cause exploitable other information external to the tunnel can cause exploitable
vulnerabilities, the tunnel method MUST provide protection against vulnerabilities, the tunnel method MUST provide protection against
modification of this additional data. modification of this additional 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.
skipping to change at page 13, line 36 skipping to change at page 13, line 30
requester that the responder is expected to understand and MUST requester that the responder is expected to understand and MUST
respond to. If the responder does not understand or support one of respond to. If the responder does not understand or support one of
the mandatory attributes in the request, it MUST ignore the rest of the mandatory attributes in the request, it MUST ignore the rest of
the attributes and send a NAK attribute to decline the request. The the attributes and send a NAK attribute to decline the request. The
NAK attribute MUST support inclusion of which mandatory attribute is NAK attribute MUST support inclusion of which mandatory attribute is
not supported. The optional attributes are attributes that are not not supported. The optional attributes are attributes that are not
mandatory to support and respond to. If the responder does not mandatory to support and respond to. If the responder does not
understand or support the optional attributes, it can ignore these understand or support the optional attributes, it can ignore these
attributes. attributes.
The payload MUST support marking of mandatory and optional
attributes, as well as a "NAK" attribute used to communicate
disagreements about received attributes.
Mandatory attributes are attributes that a receiver MUST process as
per the specification. Optional attributes are attributes that a
receiver MAY ignore.
A receiver MUST process mandatory attributes before optional ones.
After an attribute has been processed, it SHOULD be marked as no
longer being mandatory. If a receiver does not process a mandatory
attribute, it MUST ignore everything else in a request, and it MUST
send a NAK attribute in response. Similarly, if a receiver expects a
mandatory attribute and does not receive one in a request, it MUST
send a NAK attribute in the response that contains the set of
attributes it expected to receive.
The NAK attribute MUST support a description of which mandatory
attribute is either required, or is not supported. The NAK attribute
MUST be otherwise treated as an optional attribute, and it MUST NOT
contain a NAK of the NAK attribute, in order to prevent infinite
recursion.
4.3.4. Vendor Specific Support 4.3.4. Vendor Specific Support
The payload MUST support communication of an extensible set of The payload MUST support communication of an extensible set of
vendor-specific attributes. These attributes will be segmented into vendor-specific attributes. These attributes will be segmented into
uniquely identified vendor specific name spaces. They can be used uniquely identified vendor specific name spaces. They can be used
for experiments or vendor specific features. for experiments or vendor specific features.
4.3.5. Result Indication 4.3.5. Result Indication
The payload MUST support result indication and its acknowledgement, The payload MUST support result indication and its acknowledgement,
skipping to change at page 14, line 36 skipping to change at page 14, line 52
password authentication. The password authentication mentioned here password authentication. The password authentication mentioned here
refers to user or machine authentication using a legacy password refers to user or machine authentication using a legacy password
database or verifier, such as LDAP, OTP, etc. These typically database or verifier, such as LDAP, OTP, etc. These typically
require the password in its original text form in order to require the password in its original text form in order to
authenticate the peer, hence they require the peer to send the clear authenticate the peer, hence they require the peer to send the clear
text user name and password to the EAP server. text user name and password to the EAP server.
4.5.1. Security 4.5.1. Security
Many internal EAP methods have the peer send its password in the Many internal EAP methods have the peer send its password in the
clear To the EAP server. Other methods (e.g. challenge-response clear to the EAP server. Other methods (e.g. challenge-response
methods) are vulnerable to attacks if an eavesdropper can intercept methods) are vulnerable to attacks if an eavesdropper can intercept
the traffic. For any such methods, the security measures in the the traffic. For any such methods, the security measures in the
following sections MUST be met. following sections MUST be met.
4.5.1.1. Confidentiality and Integrity 4.5.1.1. Confidentiality and Integrity
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 sends the clear
clear text password to the server. text password to the server.
4.5.1.3. Server Certificate Revocation Checking 4.5.1.3. Server Certificate Revocation Checking
In some cases, the EAP peer needs to present its password to the When certificate authentication is used during tunnel establishment
server before it has network access to check the revocation status of the EAP peer may need to present its password to the server before it
the server's credentials. Therefore, the tunnel method MUST support has network access to check the revocation status of the server's
mechanisms to check the revocation status of a credential. The credentials. Therefore, the tunnel method MUST support mechanisms to
tunnel method SHOULD make use of Online Certificate Status Protocol check the revocation status of a credential. The tunnel method
(OCSP) [RFC2560] or Server-based Certificate Validation Protocol SHOULD make use of Online Certificate Status Protocol (OCSP)
(SCVP) [RFC5055] to obtain the revocation status of the EAP server [RFC2560] or Server-based Certificate Validation Protocol (SCVP)
[RFC5055] to obtain the revocation status of the EAP server
certificate. certificate.
4.5.2. Internationalization 4.5.2. Internationalization
The password authentication exchange MUST support user names and The password authentication exchange MUST support user names and
passwords in international languages. It MUST support encoding of passwords in international languages. It MUST support encoding of
user name and password strings in UTF-8 [RFC3629] format. The method user name and password strings in UTF-8 [RFC3629] format. The method
MUST specify how username and password normalizations and/or MUST specify how username and password normalizations and/or
comparisons is performed in reference to SASLPrep [RFC4013] or Net- comparisons is performed in reference to SASLPrep [RFC4013] or Net-
UTF-8 [RFC5198]. UTF-8 [RFC5198].
skipping to change at page 16, line 14 skipping to change at page 16, line 31
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. EAP methods MUST NOT be redefined inside the tunnel. 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. manipulated by intermediaries.
4.6.2. Chained Methods 4.6.2. Chained Methods
The tunnel method SHOULD support the chaining of multiple EAP The tunnel method SHOULD support the chaining of multiple EAP
methods. The tunnel method MUST allow for the communication of methods. The tunnel method MUST allow for the communication of
intermediate result and verification of compound binding between intermediate result and verification of compound binding between
executed inner methods when chained methods are employed. executed inner methods when chained methods are employed.
4.6.3. Cryptographic Binding with the TLS Tunnel 4.6.3. Cryptographic Binding with the TLS Tunnel
skipping to change at page 17, line 36 skipping to change at page 18, line 5
------- ------ ------- ------- ------ -------
| TEK | | MSK | | EMSK | | TEK | | MSK | | EMSK |
------- ------- -------- ------- ------- --------
Figure 1: Compound Keys Figure 1: Compound Keys
Furthermore, all compound keys CTK_i and all keys derived from it Furthermore, all compound keys CTK_i and all keys derived from it
SHOULD be derived in accordance to the guidelines for key derivations SHOULD be derived in accordance to the guidelines for key derivations
and key hierarchies as specified in Section 4.2.1.1.3. In and key hierarchies as specified in Section 4.2.1.1.3. In
particular, all derived keys MUST have a lifetime assigned that does particular, all derived keys MUST have a lifetime assigned that does
not exceed the lifetime of any key higher in the key hierarchy, and not exceed the lifetime of any key higher in the key hierarchy. The
MUST prevent domino effects where a compromise in one part of the derivation MUST prevent a compromise in one part of the system from
system leads to compromises in other parts of the system. leading to compromises in other parts of the system that relay on
keys at the same or higher level in the hierarchy.
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 SHOULD allow for the communication of additional The tunnel method SHOULD allow for the communication of additional
skipping to change at page 20, line 13 skipping to change at page 20, line 31
sent to the inner method server in a RADIUS password attribute which sent to the inner method server in a RADIUS password attribute which
uses weak encryption that may not be suitable protection for many uses weak encryption that may not be suitable protection for many
environments. environments.
In some cases terminating the tunnel at a different location may make In some cases terminating the tunnel at a different location may make
it difficult for a peer to authenticate the server and trust it for it difficult for a peer to authenticate the server and trust it for
further communication. For example, if the TLS tunnel is terminated further communication. For example, if the TLS tunnel is terminated
by a different organization the peer needs to be able to authenticate by a different organization the peer needs to be able to authenticate
and authorize the tunnel server to handle secret credentials that it and authorize the tunnel server to handle secret credentials that it
shares with the home server that terminates the inner method. This shares with the home server that terminates the inner method. This
may not meet the security policy of many environments." may not meet the security policy of many environments.
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-04 (work in progress), Methods", draft-clancy-emu-chbind-04 (work in progress),
November 2008. November 2008.
skipping to change at page 21, line 12 skipping to change at page 21, line 29
[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-05 (work in progress), draft-ietf-nea-pb-tnc-06 (work in progress), October 2009.
September 2009.
[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]
 End of changes. 43 change blocks. 
143 lines changed or deleted 175 lines changed or added

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