draft-ietf-emu-eaptunnel-req-09.txt   rfc6678.txt 
EMU Working Group K. Hoeper Internet Engineering Task Force (IETF) K. Hoeper
Internet-Draft Motorola, Inc. Request for Comments: 6678 Motorola Solutions, Inc.
Intended status: Informational S. Hanna Category: Informational S. Hanna
Expires: June 19, 2011 Juniper Networks ISSN: 2070-1721 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
December 16, 2010 July 2012
Requirements for a Tunnel Based EAP Method Requirements for a
draft-ietf-emu-eaptunnel-req-09.txt Tunnel-Based Extensible Authentication Protocol (EAP) Method
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 tunnel method will use Authentication Protocol (EAP) Method. This tunnel method will use
Transport Layer Security (TLS) to establish a secure tunnel. The Transport Layer Security (TLS) to establish a secure tunnel. The
tunnel will provide support for password authentication, EAP tunnel will provide support for password authentication, EAP
authentication and the transport of additional data for other authentication, and the transport of additional data for other
purposes. purposes.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on June 19, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6678.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 23
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2. Conventions Used In This Document . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 6
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 7
3.7. Client Authentication During Tunnel Establishment . . . . 8 3.7. Client Authentication during Tunnel Establishment . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . 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.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 . . . . . . . . . . . . . 12 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 11
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 . . . . . . . . 13 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13 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. 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 . . . . . . . . . . . . . . . . . . 14 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
4.3.6. Internationalization of Display Strings . . . . . . . 14 4.3.6. Internationalization of Display Strings . . . . . . . 13
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 4.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 . . . . . . . . . . . . . . . . . . . . . . . 15 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 4.5.1.3. Server Certificate Revocation Checking . . . . . . 14
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
4.6. Requirements Associated with Carrying EAP Methods . . . . 16 4.6. Requirements Associated with Carrying EAP Methods . . . . 15
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 . . . . . . . . . . . . . . . . . . . . 18 4.6.4. Peer-Initiated EAP Authentication . . . . . . . . . . 17
4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 4.6.5. Method Metadata . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
5.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18 5.4. Separation of TLS Tunnel and Inner Authentication
6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 Termination . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. Separation of TLS Tunnel and Inner Authentication 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Termination . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 23
Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23
Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
An Extensible Authentication Protocol (EAP) tunnel method is an EAP An Extensible Authentication Protocol (EAP) tunnel method is an EAP
method that establishes a secure tunnel and executes other EAP method that establishes a secure tunnel and executes other EAP
methods under the protection of that secure tunnel. An EAP tunnel methods under the protection of that secure tunnel. An EAP tunnel
method can be used in any lower layer protocol that supports EAP method can be used in any lower-layer protocol that supports EAP
authentication. There are several existing EAP tunnel methods that authentication. There are several existing EAP tunnel methods that
use Transport Layer Security (TLS) to establish the secure tunnel. use Transport Layer Security (TLS) to establish the secure tunnel.
EAP methods supporting this include Protected EAP (PEAP) [PEAP], EAP methods supporting this include Protected EAP [PEAP], Tunneled
Tunneled Transport Layer Security EAP (TTLS) [RFC5281] and EAP Transport Layer Security EAP (TTLS) [RFC5281] and EAP Flexible
Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. In
In general this has worked well so there is consensus to continue to 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 use TLS as the basis for a tunnel method. There have been various
reasons for employing a protected tunnel for EAP processes. They reasons for employing a protected tunnel for EAP processes. They
include protecting weak authentication exchanges, such as username include protecting weak authentication exchanges, such as username
and password. In addition a protected tunnel can provide means to 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 a 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 EAP Method Update (EMU) WG's method following meaning during the EAP Method Update (EMU) WG's method
selection process: 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 Lowercase 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. It is mandatory for a candidate tunnel method to supplied here. It is mandatory for a candidate tunnel method to
support all of 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 some one time password (OTP) systems and Examples of such systems are some one-time password (OTP) systems and
other systems where the username and password are submitted to an other systems where the username and password are submitted to an
external party for validation. The tunnel method MUST support external party for validation. The tunnel method MUST support
transporting cleartext username and password to the EAP server. It transporting cleartext username and password to the EAP server. It
MUST NOT reveal information about the username and password to MUST NOT reveal information about the username and password to
parties in the communication path between the peer and the EAP parties in the communication path between the peer and the EAP
Server. The advantage any attacker gains against the tunnel method server. The advantage any attacker gains against the tunnel method
when employing a username and password for authentication MUST be when employing a username and password for authentication MUST be
through interaction and not computation. The tunnel MUST support through interaction and not computation. The tunnel MUST support
protection from man-in-the-middle attacks. The combination of the protection from man-in-the-middle attacks. The combination of the
tunnel 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, an EAP-MD5 method does not provide mutual authentication or
protection from dictionary attacks. Without extra protection, EAP protection from dictionary attacks. Without extra protection, EAP
tunnel methods are vulnerable to a special type of tunnel man-in-the- tunnel methods are vulnerable to a special type of tunnel man-in-the-
middle attack [TUNNEL-MITM]. This attack is referred to as "tunnel middle (MitM) attack [TUNNEL-MITM]. This attack is referred to as
MitM attack" in the remainder of this document. The additional "tunnel MitM attack" in the remainder of this document. The
protection needed to thwart tunnel MitM attacks depends on the inner additional protection needed to thwart tunnel MitM attacks depends on
method executed within the tunnel. When weak methods are used, these the inner method executed within the tunnel. When weak methods are
attacks can be mitigated via security policies that require the used, these attacks can be mitigated via security policies that
method to be used only within a tunnel. On the other hand, a require the method to be used only within a tunnel. On the other
technical solution (so-called cryptographic bindings) can be used hand, a technical solution (so-called cryptographic bindings) can be
whenever the inner method derives key material and is not susceptible used whenever the inner method derives key material and is not
to attacks outside a tunnel. Only the latter mitigation technique susceptible to attacks outside a tunnel. Only the latter mitigation
can be made an actual requirement for EAP tunnel methods (see technique can be made an actual requirement for EAP tunnel methods
Section 4.6.3), while security policies are outside the scope of this (see Section 4.6.3), while security policies are outside the scope of
requirement draft. Please refer to the NIST Recommendation for EAP this requirement document. Please refer to the NIST "Recommendation
Methods Used in Wireless Network Access Authentication [NIST SP for EAP Methods Used in Wireless Network Access Authentication"
800-120] and [LCN 2010] for a discussion on security policies and [NIST-SP-800-120] and [LCN-2010] for a discussion on security
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 being used. However, chained EAP and also authenticate the device being used. However, chained EAP
methods from different conversations can be re-directed into the same methods from different conversations can be redirected into the same
conversation by an attacker giving the authenticator the impression conversation by an attacker giving the authenticator the impression
that both conversations terminate at the same end-point. that both conversations terminate at the same endpoint.
Cryptographic binding can be used to bind the results of chained 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
protection against attacks on method chaining. 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 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 the identities that are specific to the tunnel
Note that the peer may need to expose the realm portion of the EAP method and inner method being used. In a roaming scenario, note that
outer identity in the Network Access Identifier (NAI) [RFC4282] in a the peer may need to expose the realm portion of the EAP outer
roaming scenario in order to reach the appropriate authentication identity in the Network Access Identifier (NAI) [RFC4282] in order to
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 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-
only authentication, while still deriving keys that can be used for only authentication, while still deriving keys that can be used for
link layer security. The tunnel method MAY also allow for the bypass link-layer security. The tunnel method MAY also allow for the bypass
of server authentication processing on the client. of server authentication processing on the client.
Forgoing user or server authentication increases the chance of man- Foregoing user or server authentication increases the chance of man-
in-the-middle and other types of attacks that can compromise the in-the-middle and other types of attacks that can compromise the
derived keys used for link layer security. Therefore, passwords and derived keys used for link-layer security. Therefore, passwords and
other sensitive information MUST NOT be disclosed to an other sensitive information MUST NOT be disclosed to an
unauthenticated server, or to a server that is not authorized to unauthenticated server, or to a server that is not authorized to
authenticate the user. 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 a
TNC [RFC5793]. Depending on the specifics of the tunnel method, Posture Broker protocol compatible with Trusted Network Connect
(PB-TNC) [RFC5793]. 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.
3.7. Client Authentication During Tunnel Establishment 3.7. Client Authentication during Tunnel Establishment
In some cases the peer will have credentials that allow it to In some cases, the peer will have credentials that allow it to
authenticate during tunnel establishment. These credentials may only authenticate during tunnel establishment. These credentials may only
partially authenticate the identity of the peer and additional partially authenticate the identity of the peer and additional
authentication may be required inside the tunnel. For example, a authentication may be required inside the tunnel. For example, a
communication device may be authenticated during tunnel communication device may be authenticated during tunnel
establishment, in addition user authentication may be required to establishment; in addition, user authentication may be required to
satisfy authentication policy. The tunnel method MUST be capable of satisfy authentication policy. The tunnel method MUST be capable of
providing client side authentication during tunnel 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.
An application for extensibility is credential provisioning. When a An application for extensibility is credential provisioning. When a
peer has authenticated with EAP, this is a convenient time to peer has authenticated with EAP, this is a convenient time to
distribute credentials to that peer that may be used for later distribute credentials to that peer that may be used for later
authentication exchanges. For example, the authentication server can authentication exchanges. For example, the authentication server can
provide a private key or shared key to the peer that can be used by provide a private key or shared key to the peer that can be used by
the peer to perform rapid re-authentication or roaming. In addition the peer to perform rapid re-authentication or roaming. In addition,
there have been proposals to perform enrollment within EAP, such as there have been proposals to perform enrollment within EAP, such as
[I-D.mahy-eap-enrollment]. Another use for extensibility is support [EAP-ENROLL]. Another use for extensibility is support for alternate
for alternate authentication frameworks within the tunnel. authentication frameworks within the tunnel.
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 EAP channel bindings. new features such as EAP channel bindings.
Great care must be taken when using tunnels with no server Great care must be taken when using tunnels with no server
authentication for the protection of an inner method. For example, authentication for the protection of an inner method. For example,
the client may lack the appropriate trust roots to fully authenticate the client may lack the appropriate trust roots to fully authenticate
the server, but may still establish the tunnel to execute an inner the server, but may still establish the tunnel to execute an inner
EAP method to perform mutual authentication and key derivation. In EAP method to perform mutual authentication and key derivation. In
these cases, the inner EAP method MUST provide resistance to these cases, the inner EAP method MUST provide resistance to
dictionary attack and a cryptographic binding between the inner dictionary attack and a cryptographic binding between the inner
method and the tunnel method MUST be established. Furthermore, the method and the tunnel method MUST be established. Furthermore, the
cipher suite used to establish the tunnel MUST derive the master key cipher suite used to establish the tunnel MUST derive the master key
using contribution from both client and server, as in ephemeral using contributions from both client and server, as in ephemeral
Diffie-Hellman cipher suites. 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
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
3748 that tunnel methods MUST support protection against man-in-the- 3748 that tunnel methods MUST support protection against man-in-the-
middle attacks. Furthermore, the tunnel method MUST support identity middle attacks. Furthermore, the tunnel method MUST support identity
protection as specified in Section 7.3 in RFC 3748. protection as specified in Section 7.3 of 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 any successor. This includes the generation of the MSK, [RFC5247] or any successor. This includes the generation of the
EMSK, Peer-Id, Server-Id and Session-Id. These requirements will Master Session Key (MSK), Extended Master Session Key (EMSK),
enable the tunnel method to properly fit into the EAP key management Peer-Id, Server-Id, and Session-Id. These requirements will enable
the tunnel method to properly fit into the EAP key management
framework, maintaining all of the security properties and guarantees framework, maintaining all of the security properties and guarantees
of that 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, such as 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,
skipping to change at page 10, line 37 skipping to change at page 10, line 7
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
session keys; replay detection; keying material confidentiality and session keys; replay detection; keying material confidentiality and
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 greater than SSL 2.0 to enable the may support earlier versions greater than SSL 2.0 in order to enable
possibility of backwards compatibility. the 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-negotiation integrity check in which, as soon as
the established keys (here the tunnel key) are used to derive available, the established keys (here, the tunnel key) are used to
integrity keys. These integrity keys are then used by peer and derive integrity keys. These integrity keys are then used by the
authentication server to verify whether the cipher suite negotiation peer and authentication server to verify whether the cipher suite
has been maliciously altered by another party. negotiation 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 5.1 or [HC07] 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.
TLS provides protected cipher suite negotiation as long as all the TLS provides protected cipher suite negotiation as long as all the
cipher suites supported provide authentication, key establishment and cipher suites supported provide authentication, key establishment,
data integrity protection as discussed in Section 6.1. and data integrity protection as discussed in Section 5.1.
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
strengths of common algorithms. strengths of common algorithms.
4.2.1.1.3. Tunnel Authentication and Key Establishment 4.2.1.1.3. Tunnel Authentication and Key Establishment
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 the NIST "Draft Recommendation for Key Management", Part 3
800-57p3], i.e., the ciphersuite MUST be listed in Table 4-1, 4-2 or [NIST-SP-800-57p3], i.e., the cipher suite MUST be listed in Table
4-3 in that document. 4-1, 4-2, or 4-3 in that document.
The mandatory to implement cipher suites MUST only include cipher The mandatory-to-implement cipher suites MUST only include cipher
suites that use strong cryptographic algorithms. They MUST NOT suites that use strong cryptographic algorithms. They MUST NOT
include cipher suites providing mutually anonymous authentication or include cipher suites providing mutually anonymous authentication or
static Diffie-Hellman cipher suites. static Diffie-Hellman cipher suites.
Other ciphersuites MAY be selected following the security Other cipher suites MAY be selected following the security
requirements for tunnel protocols in NIST DRAFT Recommendation for requirements for tunnel protocols in the NIST "Recommendation for EAP
EAP Methods Used in Wireless Network Access Authentication [NIST SP Methods Used in Wireless Network Access Authentication"
800-120]. [NIST-SP-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 reuse of the authentication data can be detected as invalid.
invalid. TLS provides sufficient replay protection to meet this TLS provides sufficient replay protection to meet this requirement as
requirements as long as weak cipher suites discussed in Section 6.1 long as weak cipher suites discussed in Section 5.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
be used. For example, TLS extensions may be useful in providing MAY be used. For example, TLS extensions may be useful in providing
certificate revocation information via the TLS Online Certificate certificate revocation information via the TLS Online Certificate
Status Protocol (OCSP) extension [I-D.ietf-tls-rfc4366-bis] (thus Status Protocol (OCSP) extension [RFC6066] (thus meeting the
meeting the requirement in Section 4.5.1.3). 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
confidentially (i.e. 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
A man-in-the-middle attacker can modify clear text values such as A man-in-the-middle attacker can modify cleartext 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.
These requirements frequently express features that a candidate These requirements frequently express features that a candidate
protocol must be capable of offering so that a deployer can decide protocol must be capable of offering so that a deployer can decide
whether to make use of that feature. This section does not state whether to make use of that feature. This section does not state
requirements about what features of each protocol must be used during requirements about what features of each protocol must be used during
a deployment. a deployment.
4.3.1. Extensible Attribute Types 4.3.1. Extensible Attribute Types
The payload MUST be extensible. Some standard payload attribute The payload MUST be extensible. Some standard payload attribute
types will be defined to meet known requirements listed below, such types will be defined to meet known requirements listed below, such
as password authentication, inner EAP method, vendor specific as password authentication, inner EAP method, vendor-specific
attributes, and result indication. Additional payload attributes MAY attributes, and result indication. Additional payload attributes MAY
be defined in the future to support additional features and data be defined in the future to support additional features and data
types. types.
4.3.2. Request/Challenge Response Operation 4.3.2. Request/Challenge Response Operation
The payload MUST support request and response type of half-duplex The payload MUST support the request and response type of half-duplex
operation typical of EAP. Multiple attributes may be sent in a operation typical of EAP. Multiple attributes may be sent in a
single payload. The payload MAY support carrying on multiple single payload. The payload MAY support transporting multiple
authentications in a single payload packet. authentications in a single payload packet.
4.3.3. Indicating Criticality of Attributes 4.3.3. Indicating Criticality of Attributes
It is expected that new attributes will be defined to be carried It is expected that new attributes will be defined to be carried
within the tunnel method. In some cases it is necessary for the within the tunnel method. In some cases, it is necessary for the
sender to know if the receiver did not understand the attribute. To sender to know if the receiver did not understand the attribute. To
support this, there MUST be a way for the sender to mark attributes support this, there MUST be a way for the sender to mark attributes
such that the receiver will indicate if an attribute is not such that the receiver will indicate if an attribute is not
understood. understood.
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 namespaces. They can be used for
for experiments or vendor specific features. 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,
so both the EAP peer and server will end up with a synchronized so both the EAP peer and server will end up with a synchronized
state. The result indication is needed after each chained inner state. The result indication is needed after each chained inner
authentication method and at the end of the authentication, so authentication method and at the end of the authentication, so
separate result indication for intermediate and final result MUST be separate result indications for intermediate and final results MUST
supported. be supported.
4.3.6. Internationalization of Display Strings 4.3.6. Internationalization of Display Strings
The payload MAY provide a standard attribute format that supports The payload MAY provide a standard attribute format that supports
international strings. This attribute format MUST support encoding international strings. This attribute format MUST support encoding
strings in UTF-8 [RFC3629] format. Any strings sent by the server strings in UTF-8 [RFC3629] format. Any strings sent by the server
intended for display to the user MUST be sent in UTF-8 format and intended for display to the user MUST be sent in UTF-8 format and
SHOULD be able to be marked with language information and adapted to 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 to 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.ietf-emu-chbind]. As discussed in requirements described in [RFC6677]. As discussed in [RFC5056], EAP
[RFC5056], EAP Channel bindings differ from channel bindings channel bindings differ from channel bindings discussed in other
discussed in other contexts. Cryptographic binding between the TLS contexts. Cryptographic binding between the TLS tunnel and the inner
tunnel and the inner method discussed in Section 4.6.3 relates method discussed in Section 4.6.3 relates directly to the non-EAP
directly to the non-EAP channel binding concepts discussed in RFC channel binding concepts discussed in RFC 5056.
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 [RFC4511], OTP, etc. These database or verifier, such as the Lightweight Directory Access
typically require the password in its original text form in order to Protocol (LDAP) [RFC4511], OTP, etc. These typically require the
authenticate the peer, hence they require the peer to send the clear password in its original text form in order to authenticate the peer;
text user name and password to the EAP server. hence, they require the peer to send the cleartext username 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 cleartext password exchange MUST be integrity and confidentiality
confidentiality protected. As long as the password exchange occurs protected. As long as the password exchange occurs inside an
inside an authenticated and encrypted tunnel, this requirement is 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 sends the clear The EAP server MUST be authenticated before the peer sends the
text password to the server. cleartext password to the server.
4.5.1.3. Server Certificate Revocation Checking 4.5.1.3. Server Certificate Revocation Checking
When certificate authentication is used during tunnel establishment When certificate authentication is used during tunnel establishment,
the EAP peer may need to present its password to the server before it the EAP peer may need to present its password to the server before it
has network access to check the revocation status of the server's has network access to check the revocation status of the server's
credentials. Therefore, the tunnel method MUST support mechanisms to credentials. Therefore, the tunnel method MUST support mechanisms to
check the revocation status of a credential. The tunnel method check the revocation status of a credential. The tunnel method
SHOULD make use of Online Certificate Status Protocol (OCSP) SHOULD make use of Online Certificate Status Protocol (OCSP)
[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 usernames 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 username 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], comparisons are performed in reference to SASLprep [RFC4013],
Net-UTF-8 [RFC5198] or their replacement. Net-UTF-8 [RFC5198], or their replacements.
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 to local language. These numeric codes are not subject to
internationalization during transmission. internationalization during transmission.
4.5.3. Meta-data 4.5.3. Metadata
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 metadata that 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
authenticated. authenticated.
4.5.4. Password Change 4.5.4. Password Change
The password authentication exchange MUST support password change. The password authentication exchange MUST support password change.
The exchange SHOULD be extensible to support other "housekeeping" The exchange SHOULD be extensible to support other "housekeeping"
skipping to change at page 16, line 38 skipping to change at page 16, line 15
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
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 results and for the verification of compound binding
executed inner methods when chained methods are employed. between 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
The tunnel method MUST provide a mechanism to bind the tunnel The tunnel method MUST provide a mechanism to bind the tunnel
protocol and the inner EAP method. This property is referred to as protocol and the inner EAP method. This property is referred to as
cryptographic binding. Such bindings are an important tool for cryptographic binding. Such bindings are an important tool for
mitigating the tunnel MitM attacks on tunnel methods [TUNNEL-MITM]. mitigating the tunnel MitM attacks [TUNNEL-MITM]. Cryptographic
Cryptographic bindings enable the complete prevention of tunnel MitM bindings enable the complete prevention of tunnel MitM attacks
attacks without the need of additional security policies as long as without the need of additional security policies, as long as the
the inner method derives keys and is not vulnerable to attacks inner method derives keys and is not vulnerable to attacks outside a
outside a protected tunnel [LCN 2010]. Even though weak or non-key protected tunnel [LCN-2010]. Even though weak or non-key-deriving
deriving inner methods may be permitted, and thus security policies inner methods may be permitted. Thus, security policies preventing
preventing tunnel MitM attacks are still necessary, the tunnel method tunnel MitM attacks are still necessary, and the tunnel method MUST
MUST provide cryptographic bindings, because only this allows provide cryptographic bindings, because only this allows migrating to
migrating to more secure, policy-independent implementations. more secure, policy-independent implementations.
Cryptographic bindings are typically achieved by securely mixing the Cryptographic bindings are typically achieved by securely mixing the
established keying material (say tunnel key TK) from the tunnel established keying material (say, tunnel key TK) from the tunnel
protocol with the established keying material (say method key MK) protocol with the established keying material (say, method key MK)
from the inner authentication method(s) in order to derive fresh from the inner authentication method(s) in order to derive fresh
keying material. If chained EAP methods are executed in the tunnel, keying material. If chained EAP methods are executed in the tunnel,
all derived inner keys are combined with the tunnel key to create a all derived inner keys are combined with the tunnel key to create a
new compound tunnel key (CTK). In particular, CTK is used to derive new compound tunnel key (CTK). In particular, CTK is used to derive
the EAP MSK, EMSK and other transient keys (TEK), such as transient the EAP MSK, EMSK and other transient keys (shown as "TEK" below),
encryption keys and integrity protection keys. The key hierarchy for such as transient encryption keys and integrity protection keys. The
tunnel methods executions that derive compound keys for the purpose key hierarchy for tunnel method executions that derive compound keys
of cryptographic binding is depicted in Figure 1. for the purpose of cryptographic binding is depicted in Figure 1.
In the case of the sequential executions of n inner methods, a In the case of the sequential executions of n inner methods, a
chained compound key CTK_i MUST be computed upon the completion of chained compound key CTK_i MUST be computed upon the completion of
each inner method i such that it contains the compound key of all each inner method i such that it contains the compound key of all
previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n previous inner methods, i.e., CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n
and CTK_0=TK, where f() is a key derivation function, such as one and CTK_0=TK, where f() is a key derivation function, such as one
that complies with NIST Recommendation for Key Derivation Using that complies with the NIST "Recommendation for Key Derivation Using
Pseudorandom Functions [NIST SP 800-108]. CTK_n SHOULD serve as the Pseudorandom Functions" [NIST-SP-800-108]. CTK_n SHOULD serve as the
key to derive further keys. Figure 1 depicts the key hierarchy in key to derive further keys. Figure 1 depicts the key hierarchy in
the case of a single inner method. Transient keys derived from the the case of a single inner method. Transient keys derived from the
compound key CTK are used in a cryptographic protocol to verify the compound key CTK are used in a cryptographic protocol to verify the
integrity of the tunnel and the inner authentication method. integrity of the tunnel and the inner authentication method.
----------- -----------
| TK | MK | | TK | MK |
----------- -----------
| | | |
v v v v
skipping to change at page 18, line 5 skipping to change at page 17, line 29
| | | | | |
v v v v v v
------- ------ ------- ------- ------ -------
| 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 follow the recommendations for key derivations and key SHOULD follow the recommendations for key derivations and key
hierarchies as specified in [NIST SP 800-108]. In particular, all hierarchies as specified in [NIST-SP-800-108]. In particular, all
derived keys MUST have a lifetime assigned that does not exceed the derived keys MUST have a lifetime assigned that does not exceed the
lifetime of any key higher in the key hierarchy. The derivation MUST lifetime of any key higher in the key hierarchy. The derivation MUST
prevent a compromise in one part of the system from leading to prevent a compromise in one part of the system from leading to
compromises in other parts of the system that relay on keys at the compromises in other parts of the system that relay on keys at the
same or higher level in the hierarchy. same or higher level in the hierarchy.
4.6.4. Peer Initiated 4.6.4. Peer-Initiated EAP Authentication
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 Metadata
The tunnel method SHOULD allow for the communication of additional The tunnel method SHOULD allow for the communication of additional
data associated with an EAP method. This can be used to indicate data associated with an EAP method. This can be used to indicate
whether the authentication is for a user or a machine. This allows whether the authentication is for a user or a machine. This allows
the EAP server and peer to request and negotiate authentication the EAP server and peer to request and negotiate authentication
specifically for a user or machine. This is useful in the case of specifically for a user or machine. This is useful in the case of
multiple inner EAP authentications where the user and machine both multiple inner EAP authentications where the user and machine both
need to be authenticated. need to be authenticated.
5. IANA Considerations 5. Security Considerations
This document has no IANA considerations.
6. Security Considerations
A tunnel method is often deployed to provide mutual authentication A tunnel method is often deployed to provide mutual authentication
between EAP Peer and EAP Server and to generate key material for use between EAP Peer and EAP Server and to generate key material for use
in protecting lower layer protocols. In addition the tunnel is used in protecting lower-layer protocols. In addition the tunnel is used
to protect the communication of additional data, including peer to protect the communication of additional data, including peer
identity between the EAP Peer and EAP Server from disclosure to or identity between the EAP Peer and EAP Server from disclosure to or
modification by an attacker. These sections cover considerations modification by an attacker. These sections cover considerations
that affect the ability for a method to achieve these goals. that affect the ability for a method to achieve these goals.
6.1. Cipher Suite Selection 5.1. Cipher Suite Selection
TLS supports a wide variety of cipher suites providing a variety of TLS supports a wide range of cipher suites providing a variety of
security properties. The selection of cipher suites is critical to security properties. The selection of cipher suites is critical to
the security of the tunnel method. Selection of a cipher suite with the security of the tunnel method. Selection of a cipher suite with
weak or no authentication, such as an anonymous Diffie- Hellman based weak or no authentication, such as an anonymous Diffie-Hellman-based
cipher suite will greatly increase the risk of system compromise. cipher suite, will greatly increase the risk of system compromise.
Since a tunnel method uses the TLS tunnel to transport data, the Since a tunnel method uses the TLS tunnel to transport data, the
selection of a ciphersuite with weak data encryption and integrity selection of a cipher suite with weak data encryption and integrity
algorithms will also increase the vulnerability of the method to algorithms will also increase the vulnerability of the method to
attacks. attacks.
A tunnel protocol is prone to downgrading attacks if the tunnel A tunnel protocol is prone to downgrading attacks if the tunnel
protocol supports any key establishment algorithm that can be broken protocol supports any key establishment algorithm that can be broken
on-line. In a successful downgrading attack, an adversary breaks the on-line. In a successful downgrading attack, an adversary breaks the
selected "weak" key establishment algorithm and optionally the "weak" selected "weak" key establishment algorithm and optionally the "weak"
authentication algorithm without being detected. Here, "weak" refers authentication algorithm without being detected. Here, "weak" refers
to a key establishment algorithm that can be broken in real-time, and to a key establishment algorithm that can be broken in real-time, and
an authentication scheme that can be broken off-line, respectively. an authentication scheme that can be broken off-line, respectively.
See [KHLC07] for more details. The requirements in this document See [HC07] for more details. The requirements in this document
disapprove the use of key establishment algorithms that can be broken disapprove the use of key establishment algorithms that can be broken
on-line. on-line.
Mutually anonymous tunnel protocols are prone to man-in-the-middle Mutually anonymous tunnel protocols are prone to man-in-the-middle
attacks described in [KHLC07]. During such an attack, an adversary attacks described in [HC07]. During such an attack, an adversary
establishes a tunnel with each the peer and the authentication establishes one tunnel with the peer and one with the authentication
server, while peer and server believe that they established a tunnel server, while the peer and server believe that they established a
with each other. Once both tunnels have been established, the tunnel with each other. Once both tunnels have been established, the
adversary can eavesdrop on all communications within the tunnels, adversary can eavesdrop on all communications within the tunnels,
i.e. the execution of the inner authentication method(s). i.e., the execution of the inner authentication method(s).
Consequently, the adversary can eavesdrop on the identifiers that are Consequently, the adversary can eavesdrop on the identifiers that are
exchanged as part of the EAP method and thus, the privacy of peer exchanged as part of the EAP method, and thus the privacy of peer
and/or authentication server is compromised along with any other data and/or authentication server is compromised along with any other data
transmitted within the tunnels. This document requires server transmitted within the tunnels. This document requires server
authentication to avoid the risks associated with anonymous cipher authentication to avoid the risks associated with anonymous cipher
suites. suites.
6.2. Tunneled Authentication 5.2. Tunneled Authentication
In many cases a tunnel method provides mutual authentication by In many cases, a tunnel method provides mutual authentication by
authenticating the server during tunnel establishment and authenticating the server during tunnel establishment and
authenticating the peer within the tunnel using an EAP method. As authenticating the peer within the tunnel using an EAP method. As
described in [TUNNEL-MITM], this mode of operation can allow tunnel described in [TUNNEL-MITM], this mode of operation can allow tunnel
man-in-the-middle attackers to authenticate to the server as the peer man-in-the-middle attackers to authenticate to the server as the peer
by tunneling the inner EAP protocol messages to and from a peer by tunneling the inner EAP protocol messages to and from a peer that
executing the method outside a tunnel or with an untrustworthy is 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 are of sufficient strength that they
be broken in real-time. cannot 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 key material or only weak key material, security policies MUST be
that the peer cannot execute the inner method with the same enforced such that the peer cannot execute the inner method with the
credentials outside a protective tunnel or with an untrustworthy same credentials outside a protective tunnel or with an untrustworthy
server. server.
6.3. Data External to Tunnel 5.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
data may not need additional protection because it is implicitly data may not need additional protection because it is implicitly
verified during the protocol operation. verified during the protocol operation.
6.4. Separation of TLS Tunnel and Inner Authentication Termination 5.4. Separation of TLS Tunnel and Inner Authentication Termination
Terminating the inner method at a different location than the outer Terminating the inner method at a different location than the outer
tunnel needs careful consideration. The inner method data may be tunnel needs careful consideration. The inner method data may be
vulnerable to modification and eavesdropping between the server that vulnerable to modification and eavesdropping between the server that
terminates the tunnel and the server that terminates the inner terminates the tunnel and the server that terminates the inner
method. For example if a clear text password is used then it may be method. For example, if a cleartext password is used, then it may be
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
it difficult for a peer to authenticate the server and trust it for make it difficult for a peer to authenticate the server and trust it
further communication. For example, if the TLS tunnel is terminated for further communication. For example, if the TLS tunnel is
by a different organization the peer needs to be able to authenticate terminated by a different organization, the peer needs to be able to
and authorize the tunnel server to handle secret credentials that it authenticate and authorize the tunnel server to handle secret
shares with the home server that terminates the inner method. This credentials that the peer shares with the home server that terminates
may not meet the security policy of many environments. the inner method. This may not meet the security policy of many
environments.
7. References
7.1. Normative References
[I-D.ietf-emu-chbind]
Hartman, S., Clancy, C., and K. Hoeper, "Channel Binding
Support for EAP Methods", draft-ietf-emu-chbind-06 (work
in progress), October 2010.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 6. References
10646", STD 63, RFC 3629, November 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 6.1. Normative References
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
Authentication Protocol (EAP) Method Requirements for C. Adams, "X.509 Internet Public Key Infrastructure
Wireless LANs", RFC 4017, March 2005. Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Authorization, and Accounting (AAA) Key Management", 10646", STD 63, RFC 3629, November 2003.
BCP 132, RFC 4962, July 2007.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
Polk, "Server-Based Certificate Validation Protocol H. Levkowetz, "Extensible Authentication Protocol
(SCVP)", RFC 5055, December 2007. (EAP)", RFC 3748, June 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
(TLS) Protocol Version 1.2", RFC 5246, August 2008. Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authentication Protocol (EAP) Key Management Framework", Authorization, and Accounting (AAA) Key Management",
RFC 5247, August 2008. BCP 132, RFC 4962, July 2007.
7.2. Informative References [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
W. Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, December 2007.
[I-D.ietf-tls-rfc4366-bis] [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
3rd, D., "Transport Layer Security (TLS) Extensions: Security (TLS) Protocol Version 1.2", RFC 5246, August
Extension Definitions", draft-ietf-tls-rfc4366-bis-12 2008.
(work in progress), September 2010.
[I-D.mahy-eap-enrollment] [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Mahy, R., "An Extensible Authentication Protocol (EAP) Authentication Protocol (EAP) Key Management
Enrollment Method", draft-mahy-eap-enrollment-01 (work in Framework", RFC 5247, August 2008.
progress), March 2006.
[KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel
ICST QShine , August 2007. Binding Support for Extensible Authentication Protocol
(EAP) Methods", RFC 6677, July 2012.
[LCN 2010] 6.2. Informative References
Hoeper, K. and L. Chen, "An Inconvenient Truth about
Tunneled Authentications", Proceedings of 35th Annual IEEE
Conference on Local Computer Networks (LCN 2010) ,
September 2009.
[NIST SP 800-108] [EAP-ENROLL] Mahy, R., "An Extensible Authentication Protocol (EAP)
Chen, L., "Recommendation for Key Derivation Using Enrollment Method", Work in Progress, March 2006.
Pseudorandom Functions", Draft NIST Special
Publication 800-108, April 2008.
[NIST SP 800-120] [HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims
Hoeper, K. and L. Chen, "Recommendation for EAP Methods Fail", Institute for Computer Sciences, Social
Used in Wireless Network Access Authentication", NIST Informatics and Telecommunications Engineering (ICST),
Special Publication 800-120, September 2009. The Fourth International Conference on Heterogeneous
Networking for Quality, Reliability, Security and
Robustness (QShine 2007), August 2007.
[NIST SP 800-57] [LCN-2010] Hoeper, K. and L. Chen, "An Inconvenient Truth about
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, Tunneled Authentications", Proceedings of 35th Annual
"Recommendation for Key Management - Part 1: General IEEE Conference on Local Computer Networks (LCN 2010),
(Revised)", NIST Special Publication 800-57, part 1, September 2009.
March 2007.
[NIST SP 800-57p3] [NIST-SP-800-108]
Barker, E., Burr, W., Jones, A., Polk, W., , S., and M. Chen, L., "Recommendation for Key Derivation Using
Smid, "Recommendation for Key Management, Part 3 Pseudorandom Functions", Draft NIST Special Publication
Application-Specific Key Management Guidance", Draft NIST 800-108, April 2008.
Special Publication 800-57,part 3, October 2008.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible [NIST-SP-800-120]
Authentication Protocol (PEAP) Specification", Hoeper, K. and L. Chen, "Recommendation for EAP Methods
August 2009. Used in Wireless Network Access Authentication", NIST
Special Publication 800-120, September 2009.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names [NIST-SP-800-57]
and Passwords", RFC 4013, February 2005. Barker, E., Barker, W., Burr, W., Polk, W., and M.
Smid, "Recommendation for Key Management - Part 1:
General (Revised)", NIST Special Publication 800-57,
part 1, March 2007.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [NIST-SP-800-57p3]
Network Access Identifier", RFC 4282, December 2005. Barker, E., Burr, W., Jones, A., Polk, W., Rose, S.,
and M. Smid, "Recommendation for Key Management, Part 3
Application-Specific Key Management Guidance", Draft
NIST Special Publication 800-57, part 3, October 2008.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
(LDAP): The Protocol", RFC 4511, June 2006. Authentication Protocol (PEAP) Specification", August
2009, <http:// download.microsoft.com/download/9/5/E/
95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-
PEAP%5D.pdf>.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Flexible Authentication via Secure Tunneling Extensible Names and Passwords", RFC 4013, February 2005.
Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Channels", RFC 5056, November 2007. Network Access Identifier", RFC 4282, December 2005.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
"Transport Layer Security (TLS) Session Resumption without (LDAP): The Protocol", RFC 4511, June 2006.
Server-Side State", RFC 5077, January 2008.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
Interchange", RFC 5198, March 2008. "The Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol Method (EAP-FAST)",
RFC 4851, May 2007.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Tardo, "Network Endpoint Assessment (NEA): Overview and Channels", RFC 5056, November 2007.
Requirements", RFC 5209, June 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
Protocol Tunneled Transport Layer Security Authenticated "Transport Layer Security (TLS) Session Resumption
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. without Server-Side State", RFC 5077, January 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for
Languages", BCP 47, RFC 5646, September 2009. Network Interchange", RFC 5198, March 2008.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and
A Posture Broker (PB) Protocol Compatible with Trusted J. Tardo, "Network Endpoint Assessment (NEA): Overview
Network Connect (TNC)", RFC 5793, March 2010. and Requirements", RFC 5209, June 2008.
[TUNNEL-MITM] [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible
Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle Authentication Protocol Tunneled Transport Layer
in Tunnelled Authentication Protocols", Cryptology ePrint Security Authenticated Protocol Version 0 (EAP-
Archive: Report 2002/163, November 2002. TTLSv0)", RFC 5281, August 2008.
Appendix A. Changes from -01 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
o Added combined mutual authentication in section 3.1 Languages", BCP 47, RFC 5646, September 2009.
o Changed reference from SP 800-52 to SP 800-57,part 3
o In section 6.2 changed terminology to tunnel MitM and security
policy enforcement
o Reworded text in section 3.2 to clarify MITM protection
o Added more specific text about derivation of the CTK
o Removed resource constrained section
o Added support for Non EAP authentication as a use for
extensibility
o Added text to emergency services section to emphasize that
sensitive information should not be sent if the server is
unauthenticated.
o Reworded TLS requirements
o Reworded external data protection requirements
o Added text to section 4.6 that states method must not be re-
defined inside the tunnel.
o Editorial fixes
Appendix B. Changes from -02 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan,
o Editorial Fixes "PB-TNC: A Posture Broker (PB) Protocol Compatible with
o Clarified client authentication during tunnel establishment Trusted Network Connect (TNC)", RFC 5793, March 2010.
o Changed text so that the tunnel method MUST meet all MUST and
SHOULD requirements relevant to EAP methods in RFCs 4962 and 5247
Appendix C. changes from -03 [RFC6066] Eastlake, D., "Transport Layer Security (TLS)
o Resolution of open issues: Extensions: Extension Definitions", RFC 6066, January
http://trac.tools.ietf.org/wg/emu/trac/report/9 2011.
o Revised section 2 to match other similar RFC(Issue 6) [TUNNEL-MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-
o Cleaned up section 3.2 (issue 8) Middle in Tunnelled Authentication Protocols",
o Clarified identity protection scope in section 3.4 and Cryptology ePrint Archive: Report 2002/163, November
4.2.1.4(issue 9) 2002.
o Changed Emergency Services to anonymous authentication(section
3.5)(issue 10)
o Clarified section 4.1.1 (issue 15)
o Cleaned up TLS requirements in section 4.2.1(issue 11)
o Replaced text in 4.2.1.1.3 with suitable reference
o Improved wording in 4.2.3 and 6.3 (issue 13)
o Update internationalization requirements in 4.3.6 and 4.5.2
(Issues 25,18)
o Updated text in 4.5.1 (issue 16)
o Changed meta-data to SHOULD in 4.5.3 and 4.6.5(Issue 20)
o Changed chained methods to SHOULD in 4.6.2(issue 19)
o Added security consideration for inner method termination(issue
24)
o Updated references
o Editorial changes(issues 7,22,17)
Authors' Addresses Authors' Addresses
Katrin Hoeper Katrin Hoeper
Motorola, Inc. Motorola Solutions, Inc.
1301 E Algonquin Rd 1301 E. Algonquin Road
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Email: khoeper@motorola.com EMail: khoeper@motorolasolutions.com
Stephen Hanna Stephen Hanna
Juniper Networks Juniper Networks
3 Beverly Road 3 Beverly Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: shanna@juniper.net EMail: shanna@juniper.net
Hao Zhou Hao Zhou
Cisco Systems, Inc. Cisco Systems, Inc.
4125 Highlander Parkway 4125 Highlander Parkway
Richfield, OH 44286 Richfield, OH 44286
USA USA
Email: hzhou@cisco.com EMail: hzhou@cisco.com
Joseph Salowey (editor) Joseph Salowey (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
2901 3rd. Ave 2901 3rd. Ave
Seattle, WA 98121 Seattle, WA 98121
USA USA
Email: jsalowey@cisco.com EMail: jsalowey@cisco.com
 End of changes. 156 change blocks. 
428 lines changed or deleted 366 lines changed or added

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