draft-ietf-emu-eaptunnel-req-08.txt   draft-ietf-emu-eaptunnel-req-09.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: March 21, 2011 Juniper Networks Expires: June 19, 2011 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
September 17, 2010 December 16, 2010
Requirements for a Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-08.txt draft-ietf-emu-eaptunnel-req-09.txt
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 tunnel method will use
Layer Security (TLS) to establish a secure tunnel. The tunnel will Transport Layer Security (TLS) to establish a secure tunnel. The
provide support for password authentication, EAP authentication and tunnel will provide support for password authentication, EAP
the transport of additional data for other purposes. authentication and the transport of additional data for other
purposes.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 21, 2011. This Internet-Draft will expire on June 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7
3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7 3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8
3.7. Client Authentication During Tunnel Establishment . . . . 8 3.7. Client Authentication During Tunnel Establishment . . . . 8
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
3.9. Certificate-less Authentication and Generic EAP Method 3.9. Certificate-less Authentication and Generic EAP Method
Extension . . . . . . . . . . . . . . . . . . . . . . . . 9 Extension . . . . . . . . . . . . . . . . . . . . . . . . 9
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.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 . . . . . . 11
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 . . . . . . . . . . . . . 12
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . 13
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13 4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Running EAP methods within a TLS protected tunnel has been deployed An Extensible Authentication Protocol (EAP) tunnel method is an EAP
in several different solutions. EAP methods supporting this include method that establishes a secure tunnel and executes other EAP
PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this methods under the protection of that secure tunnel. An EAP tunnel
has worked well so there is consensus to continue to use TLS as the method can be used in any lower layer protocol that supports EAP
basis for a tunnel method. There have been various reasons for authentication. There are several existing EAP tunnel methods that
employing a protected tunnel for EAP processes. They include use Transport Layer Security (TLS) to establish the secure tunnel.
protecting weak authentication exchanges, such as username and EAP methods supporting this include Protected EAP (PEAP) [PEAP],
password. In addition a protected tunnel can provide means to Tunneled Transport Layer Security EAP (TTLS) [RFC5281] and EAP
Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851].
In general this has worked well so there is consensus to continue to
use TLS as the basis for a tunnel method. There have been various
reasons for employing a protected tunnel for EAP processes. They
include protecting weak authentication exchanges, such as username
and password. In addition a protected tunnel can provide means to
provide peer identity protection and EAP method chaining. Finally, provide peer identity protection and EAP method chaining. Finally,
systems have found it useful to transport additional types of data systems have found it useful to transport additional types of data
within the protected tunnel. within the protected tunnel.
This document describes the requirements for an EAP tunnel method as This document describes the requirements for a 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
Use of each capitalized word within a sentence or phrase carries the Use of each capitalized word within a sentence or phrase carries the
following meaning during the EMU WG's method selection process: following meaning during the EAP Method Update (EMU) WG's method
selection process:
MUST - indicates an absolute requirement MUST - indicates an absolute requirement
MUST NOT - indicates something absolutely prohibited MUST NOT - indicates something absolutely prohibited
SHOULD - indicates a strong recommendation of a desired result SHOULD - indicates a strong recommendation of a desired result
SHOULD NOT - indicates a strong recommendation against a result SHOULD NOT - indicates a strong recommendation against a result
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 needs to support all of supplied here. It is mandatory for a candidate tunnel method to
the use cases that are marked below as "MUST". support all of 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 some one time password (OTP) systems and
systems where the username and password are submitted to an external other systems where the username and password are submitted to an
party for validation. The tunnel method MUST support transporting external party for validation. The tunnel method MUST support
cleartext username and password to the EAP server. It MUST NOT transporting cleartext username and password to the EAP server. It
reveal information about the username and password to parties in the MUST NOT reveal information about the username and password to
communication path between the peer and the EAP Server. The parties in the communication path between the peer and the EAP
advantage any attacker gains against the tunneled method when Server. The advantage any attacker gains against the tunnel method
employing a username and password for authentication MUST be through when employing a username and password for authentication MUST be
interaction and not computation. The tunnel MUST support protection through interaction and not computation. The tunnel MUST support
from man-in-the-middle attacks. The combination of the tunnel protection from man-in-the-middle attacks. The combination of the
authentication and password authentication MUST enable mutual tunnel authentication and password authentication MUST enable mutual
authentication. 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 EAP-MD5 does not provide mutual authentication or example, a EAP-MD5 does not provide mutual authentication or
protection from dictionary attacks. Without extra protection, protection from dictionary attacks. Without extra protection, EAP
tunnel-based EAP methods are vulnerable to a special type of tunnel tunnel methods are vulnerable to a special type of tunnel man-in-the-
man-in-the-middle attack [TUNNEL-MITM]. This attack is referred to middle attack [TUNNEL-MITM]. This attack is referred to as "tunnel
as "tunnel MitM attack" in the remainder of this document. The MitM attack" in the remainder of this document. The additional
additional protection needed to thwart tunnel MitM attacks depends on protection needed to thwart tunnel MitM attacks depends on the inner
the inner method executed within the tunnel. When weak methods are method executed within the tunnel. When weak methods are used, these
used, these attacks can be mitigated via security policies that attacks can be mitigated via security policies that require the
require the method to be used only within a tunnel. On the other method to be used only within a tunnel. On the other hand, a
hand, a technical solution (so-called cryptographic bindings) can be technical solution (so-called cryptographic bindings) can be used
used whenever the inner method derives key material and is not whenever the inner method derives key material and is not susceptible
susceptible to attacks outside a tunnel. Only the latter mitigation to attacks outside a tunnel. Only the latter mitigation technique
technique can be made an actual requirement for tunnel-based EAP can be made an actual requirement for EAP tunnel methods (see
methods (see Section 4.6.3), while security policies are outside the Section 4.6.3), while security policies are outside the scope of this
scope of this requirement draft. Please refer to the NIST requirement draft. Please refer to the NIST Recommendation for EAP
Recommendation for EAP Methods Used in Wireless Network Access Methods Used in Wireless Network Access Authentication [NIST SP
Authentication [NIST SP 800-120] and [LCN 2010] for a discussion on 800-120] and [LCN 2010] for a discussion on security policies and
security policies and complete solutions for thwarting tunnel MitM complete solutions for thwarting tunnel MitM attacks.
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
skipping to change at page 7, line 36 skipping to change at page 7, line 42
When performing an EAP authentication, the peer may want to protect When performing an EAP authentication, the peer may want to protect
its identity and only disclose it to a trusted EAP server. This its identity and only disclose it to a trusted EAP server. This
helps to maintain peer privacy. helps to maintain peer privacy.
The tunnel method MUST support identity protection, therefore the The tunnel method MUST support identity protection, therefore the
identity of the peer used for authentication purposes MUST NOT be identity of the peer used for authentication purposes MUST NOT be
obtainable by any entity other than the EAP server terminating the obtainable by any entity other than the EAP server terminating the
tunnel method. Peer identity protection provided by the tunnel tunnel method. Peer identity protection provided by the tunnel
method applies to tunnel method and inner method specific identities. method applies to tunnel method and inner method specific identities.
Note that the peer may need to expose the realm portion of the EAP Note that the peer may need to expose the realm portion of the EAP
outer identity in the NAI [RFC4282] in a roaming scenario in order to outer identity in the Network Access Identifier (NAI) [RFC4282] in a
reach the appropriate authentication server. roaming scenario in order to 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 a When network service is provided, it is sometimes desirable for a
user to gain network access in order to access limited services for user to gain network access in order to access limited services for
emergency communication or troubleshooting information. To avoid emergency communication or troubleshooting information. To avoid
eavesdropping, it's best to negotiate link layer security as with any eavesdropping, it's best to negotiate link 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-
skipping to change at page 9, line 15 skipping to change at page 9, line 22
3.9. Certificate-less Authentication and Generic EAP Method Extension 3.9. Certificate-less Authentication and Generic EAP Method Extension
In some cases the peer will not have a way to verify a server In some cases the peer will not have a way to verify a server
certificate and in some cases a server might not have a certificate certificate and in some cases a server might not have a certificate
to verify. Therefore, it is desirable to support certificate-less to verify. Therefore, it is desirable to support certificate-less
authentication. An application for this is credential provisioning authentication. An application for this is credential provisioning
where the peer and server authenticate each other with a shared where the peer and server authenticate each other with a shared
password and credentials for subsequent authentication (e.g. a key password and credentials for subsequent authentication (e.g. a key
pair and certificate or a shared key) can be passed inside the pair and certificate or a shared key) can be passed inside the
tunnel. Another application is to extend existing EAP methods with tunnel. Another application is to extend existing EAP methods with
new features such as channel bindings. new features such as EAP channel bindings.
Great care must be taken when attempting to perform certificate-less Great care must be taken when using tunnels with no server
authentication. One way of doing it is to establish the tunnel authentication for the protection of an inner method. For example,
without full server or client verification and inside the tunnel use the client may lack the appropriate trust roots to fully authenticate
an EAP method that performs mutual authentication and key derivation. the server, but may still establish the tunnel to execute an inner
If this technique is used the inner EAP method MUST provide EAP method to perform mutual authentication and key derivation. In
resistance to dictionary attack and a cryptographic binding between these cases, the inner EAP method MUST provide resistance to
the inner method and the tunnel method MUST be established. In dictionary attack and a cryptographic binding between the inner
addition the cipher suite used to establish the tunnel MUST derive method and the tunnel method MUST be established. Furthermore, the
the master key using contribution from both client and server, as in cipher suite used to establish the tunnel MUST derive the master key
ephemeral Diffie-Hellman cipher suites. using contribution from both client and server, as in ephemeral
Diffie-Hellman cipher suites.
The tunnel method MAY allow for certificate-less authentication. The tunnel method MAY allow for certificate-less authentication.
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
skipping to change at page 10, line 33 skipping to change at page 10, line 43
integrity; and confirmation of cipher suite selection. integrity; and confirmation of cipher suite selection.
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 greater than SSL 2.0 to enable the
compatibility. possibility of backwards compatibility.
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
skipping to change at page 11, line 33 skipping to change at page 11, line 42
A tunnel method MUST provide unidirectional authentication from A tunnel method MUST provide unidirectional authentication from
authentication server to EAP peer and mutual authentication between authentication server to EAP peer and mutual authentication between
authentication server and EAP peer. The tunnel method MUST provide authentication server and EAP peer. The tunnel method MUST provide
at least one mandatory to implement cipher suite that provides at least one mandatory to implement cipher suite that provides
certificate-based authentication of the server and provides optional certificate-based authentication of the server and provides optional
certificate-based authentication of the client. Other types of certificate-based authentication of the client. Other types of
authentication MAY be supported. authentication MAY be supported.
At least one mandatory to implement cipher suite MUST be approved by At least one mandatory to implement cipher suite MUST be approved by
NIST DRAFT Recommendation for Key Management, Part 3 [NIST SP NIST Draft Recommendation for Key Management, Part 3 [NIST SP
800-57p3], i.e., the ciphersuite MUST be listed in Table 4-1, 4-2 or 800-57p3], i.e., the ciphersuite MUST be listed in Table 4-1, 4-2 or
4-3 in that document. 4-3 in that document.
The mandatory to implement cipher suites MUST NOT include "export The mandatory to implement cipher suites MUST only include cipher
strength" cipher suites, cipher suites providing mutually anonymous suites that use strong cryptographic algorithms. They MUST NOT
authentication or static Diffie-Hellman cipher suites. include cipher suites providing mutually anonymous authentication or
static Diffie-Hellman cipher suites.
Other ciphersuites MAY be selected following the security Other ciphersuites MAY be selected following the security
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 provides sufficient replay protection to meet this invalid. TLS provides sufficient replay protection to meet this
requirements as long as weak cipher suites discussed in Section 6.1 requirements as long as weak cipher suites discussed in Section 6.1
are avoided. are avoided.
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 Online Certificate
Status Protocol (OCSP) extension [I-D.ietf-tls-rfc4366-bis] (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 establishment of the tunnel and protection of inner method applies to establishment of the tunnel and protection of inner method
specific identities. If applicable, the peer certificate is sent specific identities. If applicable, the peer certificate is sent
skipping to change at page 14, line 22 skipping to change at page 14, line 32
SHOULD be able to be marked with language information and adapted to SHOULD be able to be marked with language information and adapted to
the user's language preference as indicated by RFC 5646 [RFC5646]. the user's language preference as indicated by RFC 5646 [RFC5646].
Note that in some cases, such as when transmitting error codes, it is Note that in some cases, such as when transmitting error codes, it is
acceptable to exchange numeric codes that can be translated by the acceptable to exchange numeric codes that can be translated by the
client to support the particular local language. These numeric codes client to support the particular local language. These numeric codes
are not subject internationalization during transmission. are not subject internationalization during transmission.
4.4. EAP Channel Binding Requirements 4.4. EAP Channel Binding Requirements
The tunnel method MUST be capable of meeting EAP channel binding The tunnel method MUST be capable of meeting EAP channel binding
requirements described in [I-D.clancy-emu-chbind]. requirements described in [I-D.ietf-emu-chbind]. As discussed in
[RFC5056], EAP Channel bindings differ from channel bindings
discussed in other contexts. Cryptographic binding between the TLS
tunnel and the inner method discussed in Section 4.6.3 relates
directly to the non-EAP channel binding concepts discussed in RFC
5056.
4.5. Requirements Associated with Carrying Username and Passwords 4.5. Requirements Associated with Carrying Username and Passwords
This section describes the requirements associated with tunneled This section describes the requirements associated with tunneled
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 [RFC4511], OTP, etc. These
require the password in its original text form in order to typically 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.
skipping to change at page 15, line 28 skipping to change at page 15, line 43
[RFC2560] or Server-based Certificate Validation Protocol (SCVP) [RFC2560] or Server-based Certificate Validation Protocol (SCVP)
[RFC5055] to obtain the revocation status of the EAP server [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],
UTF-8 [RFC5198]. Net-UTF-8 [RFC5198] or their replacement.
Any strings sent by the server intended for display to the user MUST Any strings sent by the server intended for display to the user MUST
be sent in UTF-8 format and SHOULD be able to be marked with language be sent in UTF-8 format and SHOULD be able to be marked with language
information and adapted to the user's language preference as information and adapted to the user's language preference as
indicated by RFC 5646 [RFC5646]. Note that in some cases, such as indicated by RFC 5646 [RFC5646]. Note that in some cases, such as
when transmitting error codes, it is acceptable to exchange numeric when transmitting error codes, it is acceptable to exchange numeric
codes that can be translated by the client to support the particular codes that can be translated by the client to support the particular
local language. These numeric codes are not subject local language. These numeric codes are not subject to
internationalization during transmission. internationalization during transmission.
4.5.3. Meta-data 4.5.3. Meta-data
The password authentication exchange SHOULD support additional The password authentication exchange SHOULD support additional
associated meta-data which can be used to indicate whether the associated meta-data which can be used to indicate whether the
authentication is for a user or a machine. This allows the EAP authentication is for a user or a machine. This allows the EAP
server and peer to request and negotiate authentication specifically server and peer to request and negotiate authentication specifically
for a user or machine. This is useful in the case of multiple inner for a user or machine. This is useful in the case of multiple inner
authentications where the user and machine both need to be authentications where the user and machine both need to be
skipping to change at page 19, line 38 skipping to change at page 19, line 50
by tunneling the inner EAP protocol messages to and from a peer by tunneling the inner EAP protocol messages to and from a peer
executing the method outside a tunnel or with an untrustworthy executing the method outside a tunnel or with an untrustworthy
server. Cryptographic binding between the established keying server. Cryptographic binding between the established keying
material from the inner authentication method(s) and the tunnel material from the inner authentication method(s) and the tunnel
protocol verifies that the endpoints of the tunnel and the inner protocol verifies that the endpoints of the tunnel and the inner
authentication method(s) are the same. This can thwart the attack if authentication method(s) are the same. This can thwart the attack if
the inner method derived keys of sufficient strength that they cannot the inner method derived keys of sufficient strength that they cannot
be broken 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, security policies must be enforced such or only weak key material, security policies MUST be enforced such
that the peer cannot execute the inner method with the same that the peer cannot execute the inner method with the same
credentials outside a protective tunnel or with an untrustworthy credentials outside a protective tunnel or with an untrustworthy
server. 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 from modification. In some cases external MUST protect this data from modification. In some cases external
skipping to change at page 20, line 28 skipping to change at page 20, line 39
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.ietf-emu-chbind]
Clancy, C. and K. Hoeper, "Channel Binding Support for EAP Hartman, S., Clancy, C., and K. Hoeper, "Channel Binding
Methods", draft-clancy-emu-chbind-04 (work in progress), Support for EAP Methods", draft-ietf-emu-chbind-06 (work
November 2008. in progress), October 2010.
[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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
skipping to change at page 21, line 18 skipping to change at page 21, line 30
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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-tls-rfc4366-bis]
3rd, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", draft-ietf-tls-rfc4366-bis-12
(work in progress), September 2010.
[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.
[LCN 2010] [LCN 2010]
Hoeper, K. and L. Chen, "An Inconvenient Truth about Hoeper, K. and L. Chen, "An Inconvenient Truth about
skipping to change at page 22, line 15 skipping to change at page 22, line 32
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP) Specification", Authentication Protocol (PEAP) Specification",
August 2009. August 2009.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005. and Passwords", RFC 4013, February 2005.
[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.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851, Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007. May 2007.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008. Requirements", RFC 5209, June 2008.
 End of changes. 36 change blocks. 
90 lines changed or deleted 117 lines changed or added

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