draft-ietf-emu-eaptunnel-req-03.txt   draft-ietf-emu-eaptunnel-req-04.txt 
EMU Working Group K. Hoeper EMU Working Group K. Hoeper
Internet-Draft Motorola, Inc. Internet-Draft Motorola, Inc.
Intended status: Informational S. Hanna Intended status: Informational S. Hanna
Expires: January 7, 2010 Juniper Networks Expires: April 10, 2010 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
July 6, 2009 October 7, 2009
Requirements for a Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-03.txt draft-ietf-emu-eaptunnel-req-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010. This Internet-Draft will expire on April 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used In This Document . . . . . . . . . . . . . . 5 2. Conventions Used In This Document . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7
3.5. Emergency Services Authentication . . . . . . . . . . . . 7 3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8
3.7. Client Authentication During Tunnel Establishment . . . . 8 3.7. Client Authentication During Tunnel Establishment . . . . 8
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 11
4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 13 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 13 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 13 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . 14 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13
4.3.2. Request/Challenge Response Operation . . . . . . . . . 14 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 14 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13
4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 14 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 . . . . . . . 15 4.3.6. Internationalization of Display Strings . . . . . . . 14
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 15 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and 4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . 15
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 16 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 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 . . . . 16
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 17 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 18 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17
4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 19 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 20 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
6.4. Separation of TLS Tunnel and Inner Authentication
Termination . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 22
Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23
Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Running EAP methods within a TLS protected tunnel has been deployed Running EAP methods within a TLS protected tunnel has been deployed
in several different solutions. EAP methods supporting this include in several different solutions. EAP methods supporting this include
PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this has PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this
worked well so there is consensus to continue to use TLS as the basis has worked well so there is consensus to continue to use TLS as the
for a tunnel method. There have been various reasons for employing a basis for a tunnel method. There have been various reasons for
protected tunnel for EAP processes. They include protecting weak employing a protected tunnel for EAP processes. They include
authentication exchanges, such as username and password. In addition protecting weak authentication exchanges, such as username and
a protected tunnel can provide means to provide peer identity password. In addition a protected tunnel can provide means to
protection and EAP method chaining. Finally, systems have found it provide peer identity protection and EAP method chaining. Finally,
useful to transport additional types of data within the protected systems have found it useful to transport additional types of data
tunnel. within the protected tunnel.
This document describes the requirements for an EAP tunnel method as This document describes the requirements for an EAP tunnel method as
well as for a password protocol supporting legacy password well as for a password protocol supporting legacy password
verification within the tunnel method. verification within the tunnel method.
2. Conventions Used In This Document 2. Conventions Used In This Document
Because this specification is an informational specification (not
able to directly use [RFC2119]), the following capitalized words are
used to express requirements language used in this specification.
Use of each capitalized word within a sentence or phrase carries the Use of each capitalized word within a sentence or phrase carries the
following meaning during the EMU WG's method selection process: following meaning during the EMU WG's method selection process:
MUST - indicates an absolute requirement MUST - indicates an absolute requirement
MUST NOT - indicates something absolutely prohibited MUST NOT - indicates something absolutely prohibited
SHOULD - indicates a strong recommendation of a desired result SHOULD - indicates a strong recommendation of a desired result
SHOULD NOT - indicates a strong recommendation against a result SHOULD NOT - indicates a strong recommendation against a result
skipping to change at page 6, line 14 skipping to change at page 6, line 14
3.1. Password Authentication 3.1. Password Authentication
Many legacy systems only support user authentication with passwords. Many legacy systems only support user authentication with passwords.
Some of these systems require transport of the actual username and Some of these systems require transport of the actual username and
password to the authentication server. This is true for systems password to the authentication server. This is true for systems
where the authentication server does not have access to the cleartext where the authentication server does not have access to the cleartext
password or a consistent transform of the cleartext password. password or a consistent transform of the cleartext password.
Example of such systems are one time password (OTP) systems and other Example of such systems are one time password (OTP) systems and other
systems where the username and password are submitted to an external systems where the username and password are submitted to an external
party for validation. The tunnel method MUST support this use case. party for validation. The tunnel method MUST support transporting
However, it MUST NOT expose the username and password to parties in username and password to the authentication server. However, it MUST
the communication path between the peer and the EAP Server and it NOT expose the username and password to parties in the communication
MUST provide protection against man-in-the-middle and dictionary path between the peer and the EAP Server and it MUST provide
attacks. The combination of the tunnel authentication and password protection against man-in-the-middle and dictionary attacks. The
authentication MUST enable mutual authentication. combination of the tunnel authentication and password authentication
MUST enable mutual authentication.
Since EAP authentication occurs before network access is granted the Since EAP authentication occurs before network access is granted the
tunnel method SHOULD enable an inner exchange to provide support for tunnel method SHOULD enable an inner exchange to provide support for
minimal password management tasks including password change, "new PIN minimal password management tasks including password change, "new PIN
mode", and "next token mode" required by some systems. mode", and "next token mode" required by some systems.
3.2. Protection of Weak EAP Methods 3.2. Protection of Weak EAP Methods
Some existing EAP methods have vulnerabilities that could be Some existing EAP methods have vulnerabilities that could be
eliminated or reduced by running them inside a protected tunnel. For eliminated or reduced by running them inside a protected tunnel. For
skipping to change at page 6, line 50 skipping to change at page 6, line 51
a technical solution (so-called cryptographic bindings) can be used a technical solution (so-called cryptographic bindings) can be used
whenever the inner method is not susceptible to attacks outside a whenever the inner method is not susceptible to attacks outside a
tunnel and derives keying material. Only the latter mitigation tunnel and derives keying material. Only the latter mitigation
technique can be made an actual requirement for tunnel-based EAP technique can be made an actual requirement for tunnel-based EAP
methods (see Section 4.6.3), while security policies are outside the methods (see Section 4.6.3), while security policies are outside the
scope of this requirement draft. Please refer to the NIST scope of this requirement draft. Please refer to the NIST
Recommendation for EAP Methods Used in Wireless Network Access Recommendation for EAP Methods Used in Wireless Network Access
Authentication [NIST SP 800-120] for a discussion on security Authentication [NIST SP 800-120] for a discussion on security
policies and complete solutions for thwarting tunnel MitM attacks. policies and complete solutions for thwarting tunnel MitM attacks.
The tunnel method MUST support protection of weak EAP methods, The tunnel method MUST support protection of weak EAP methods.
including cryptographic protection from tunnel MitM attacks. In Cryptographic protection from tunnel MitM attacks MUST be provided
combination with an appropriate security policy this will thwart MitM for all key generating methods. In combination with an appropriate
attacks against inner methods. security policy this will thwart MitM attacks against inner methods.
3.3. Chained EAP Methods 3.3. Chained EAP Methods
Several circumstances are best addressed by using chained EAP Several circumstances are best addressed by using chained EAP
methods. For example, it may be desirable to authenticate the user methods. For example, it may be desirable to authenticate the user
and also authenticate the device that he or she is using. However, and also authenticate the device that he or she is using. However,
chained EAP methods from different conversations can be re-directed chained EAP methods from different conversations can be re-directed
into the same conversation by an attacker giving the authenticator into the same conversation by an attacker giving the authenticator
the impression that both conversations terminate at the same end- the impression that both conversations terminate at the same end-
point. Cryptographic binding can be used to bind the results of key point. Cryptographic binding can be used to bind the results of key
skipping to change at page 7, line 30 skipping to change at page 7, line 31
3.4. Identity Protection 3.4. Identity Protection
When performing an EAP authentication, the peer may want to protect When performing an EAP authentication, the peer may want to protect
its identity, only disclosing its identity to a trusted backend its identity, only disclosing its identity to a trusted backend
authentication server. This helps to maintain the privacy of the authentication server. This helps to maintain the privacy of the
peer's identity. peer's identity.
The tunnel method MUST support identity protection, ensuring that The tunnel method MUST support identity protection, ensuring that
peer identity is not disclosed to the authenticator and any other peer identity is not disclosed to the authenticator and any other
intermediaries before the server that terminates the tunnel method. intermediaries before the server that terminates the tunnel method.
Note that the peer may need to expose the realm portion of the EAP Peer identity protection provided by the tunnel method applies to
outer identity in the NAI [RFC4282] in a roaming scenario in order to tunnel method and inner method specific identities. Note that the
reach the appropriate authentication server. peer may need to expose the realm portion of the EAP outer identity
in the NAI [RFC4282] in a roaming scenario in order to reach the
appropriate authentication server.
3.5. Emergency Services Authentication 3.5. Anonymous Service Access
When wireless VOIP service is provided, some regulations require any When network service is provided, it is sometimes desirable for any
user to be able to gain access to the network to make an emergency user to be able to gain access to the network to enable access to
telephone call. To avoid eavesdropping on this call, it's best to limited services emergency communication or troubleshooting
negotiate link layer security as with any other authentication. information. To avoid eavesdropping, it's best to negotiate link
layer security as with any other authentication.
Therefore, the tunnel method SHOULD allow anonymous peers or server- Therefore, the tunnel method SHOULD allow anonymous peers or server-
only authentication, but still derive keys that can be used for link only authentication, but still derive keys that can be used for link
layer security. The tunnel method MAY also allow for the bypass of layer security. The tunnel method MAY also allow for the bypass of
server authentication processing on the client. Forgoing server authentication processing on the client. Forgoing
authentication increases the chance of man-in-the-middle and other authentication increases the chance of man-in-the-middle and other
types of attacks that can compromise the derived keys used for link types of attacks that can compromise the derived keys used for link
layer security. In addition, passwords and other sensitive layer security. In addition, passwords and other sensitive
information must not be disclosed to an unauthenticated or information must not be disclosed to an unauthenticated or
unauthorized server. unauthorized server.
skipping to change at page 9, line 23 skipping to change at page 9, line 26
protection as specified in Section 7.3 in RFC 3748. protection as specified in Section 7.3 in RFC 3748.
The tunnel method MUST be unconditionally compliant with RFC 4017 The tunnel method MUST be unconditionally compliant with RFC 4017
[RFC4017] (using the definition of "unconditionally compliant" [RFC4017] (using the definition of "unconditionally compliant"
contained in section 1.1 of RFC 4017). This means that the method contained in section 1.1 of RFC 4017). This means that the method
MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT
requirements in RFC 4017. requirements in RFC 4017.
The tunnel method MUST meet all the MUST and SHOULD requirements The tunnel method MUST meet all the MUST and SHOULD requirements
relevant to EAP methods contained in the EAP Key Management Framework relevant to EAP methods contained in the EAP Key Management Framework
[RFC5247] or its successor. The tunnel method MUST include MSK and [RFC5247] or its successor. This includes the generation of the MSK,
EMSK generation. This will enable the tunnel method to properly fit EMSK, Peer-Id, Server-Id and Session-Id. This will enable the tunnel
into the EAP key management framework, maintaining all of the method to properly fit into the EAP key management framework,
security properties and guarantees of that framework. maintaining all of the security properties and guarantees of that
framework.
The tunnel method MUST NOT be tied to any single cryptographic The tunnel method MUST NOT be tied to any single cryptographic
algorithm. Instead, it MUST support run-time negotiation to select algorithm. Instead, it MUST support run-time negotiation to select
among an extensible set of cryptographic algorithms. This among an extensible set of cryptographic algorithms. This includes
"cryptographic algorithm agility" provides several advantages. Most algorithms used with certificates presented during tunnel
important, when a weakness in an algorithm is discovered or increased establishment. This "cryptographic algorithm agility" provides
processing power overtakes an algorithm, users can easily transition several advantages. Most important, when a weakness in an algorithm
to a new algorithm. Also, users can choose the algorithm that best is discovered or increased processing power overtakes an algorithm,
meets their needs. users can easily transition to a new algorithm. Also, users can
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; confirm cipher suite selection; and uniquely named keys. integrity; and confirmation of cipher suite selection.
4.1.2. Draw from Existing Work 4.1.2. Draw from Existing Work
Several existing tunnel methods are already in widespread usage: EAP- Several existing tunnel methods are already in widespread usage: EAP-
FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable
experience has been gained from various deployments with these experience has been gained from various deployments with these
methods. This experience SHOULD be considered when evaluating tunnel methods. This experience SHOULD be considered when evaluating tunnel
methods. If one of these existing tunnel methods can meet the methods. If one of these existing tunnel methods can meet the
requirements contained in this specification then that method SHOULD requirements contained in this specification then that method SHOULD
be preferred over a new method. be preferred over a new method.
skipping to change at page 10, line 18 skipping to change at page 10, line 22
and security analysis can be gained. and security analysis can be gained.
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
SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to may support earlier versions to enable the possibility of backwards
enable the possibility of backwards compatibility with existing compatibility. The following section discusses requirements for TLS
deployments. The following section discusses requirements for TLS
Tunnel Establishment. Tunnel Establishment.
4.2.1.1. Cipher Suites 4.2.1.1. Cipher Suites
4.2.1.1.1. Cipher Suite Negotiation 4.2.1.1.1. Cipher Suite Negotiation
Cipher suite negotiations always suffer from downgrading attacks when Cipher suite negotiations always suffer from downgrading attacks when
they are not secured by any kind of integrity protection. A common they are not secured by any kind of integrity protection. A common
practice is a post integrity check in which, as soon as available, practice is a post integrity check in which, as soon as available,
the established keys (here the tunnel key) are used to derive the established keys (here the tunnel key) are used to derive
skipping to change at page 11, line 11 skipping to change at page 11, line 19
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 or 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 meet the At least one mandatory to implement cipher suite MUST be approved by
following requirements for secure key establishment along with the NIST DRAFT Recommendation for Key Management, Part 3 [NIST SP
previous requirements for authentication and data protection 800-57p3], i.e., the ciphersuite MUST be listed in Table 4-1, 4-2 or
algorithms: 4-3 in that document.
o One-way key derivation, i.e., a compromised key leads to the
compromise of all descendant keys but does not affect the security
of any precedent key in the same branch of the key hierarchy.
o Cryptographically separated keys, i.e., a compromised key in one
branch of the key hierarchy does not affect the security of keys
in other branches.
o Cryptographically separated entities, i.e., keys held by different
entities are cryptographically separate. As a result, the
compromise of a single peer does not compromise keying material
held by any other peer within the system, including session keys
and long-term keys.
o Identity binding, i.e., each derived key is bound to the EAP peer
and authentication server by including their identifiers as input
to the key derivation.
o Context binding, i.e., each derived key is bound to its context by
including appropriate key labels in the input of the key
derivation.
o Key lifetime, i.e., each key has a lifetime assigned that does not
exceed the lifetime of any key higher in the key hierarchy.
o Mutual implicit key authentication, i.e., the keying material
derived upon a successful key establishment execution is only
known to the EAP peer and authentication server and is kept
confidential.
o Key freshness, i.e. EAP peer and EAP server are assured that the
derived keys are fresh and the re-use of expired key material is
prevented. The freshness property is typically achieved by using
one or more of the following techniques: nonces, sequence numbers,
timestamps.
The mandatory to implement cipher suites MUST NOT include "export The mandatory to implement cipher suites MUST NOT include "export
strength" cipher suites, cipher suites providing mutually anonymous strength" cipher suites, cipher suites providing mutually anonymous
authentication or static Diffie-Hellman cipher suites. Part 3 of the authentication or static Diffie-Hellman cipher suites.
NIST Recommendation for Key Management [NIST SP 800-57p3] can be
consulted for a list of acceptable TLS v1.0, v1.1 and v 1.2 cipher
suites and NIST Recommendation for Key Derivation Using Pseudorandom
Functions [NIST SP 800-108] for additional information on secure key
derivation.
In addition a tunnel method SHOULD provide cipher suites to meet the
following additional recommendations for good key establishment
algorithms:
o Key control , i.e., EAP peer and authentication server each
contribute to the key computation of the tunnel key. This
property prevents that a single protocol participant controls the
value of an established key. In that way, protocol participants
can ensure that generated keys are fresh and have good random
properties.
o Key confirmation, i.e., one protocol participant is assured that
another participant actually possesses a particular secret key.
In the case of mutual key confirmation both the EAP peer and the
authentication server are assured that they possess the same key.
Key confirmation is commonly achieved by using one of the derived
keys to generate a message authentication code. Mutual key
confirmation combined with mutual implicit key authentication
leads to mutual explicit key authentication.
o Forward secrecy (FS), i.e., if a long-term secret key is Other ciphersuites MAY be selected following the security
compromised, it does not compromise keys that have been requirements for tunnel protocols in NIST DRAFT Recommendation for
established in previous EAP executions. This property is EAP Methods Used in Wireless Network Access Authentication [NIST SP
typically achieved by executing an ephemeral Diffie-Hellman key 800-120].
establishment.
4.2.1.2. Tunnel Replay Protection 4.2.1.2. Tunnel Replay Protection
In order to prevent replay attacks on a tunnel protocol, the message In order to prevent replay attacks on a tunnel protocol, the message
authentication MUST be generated using a time-variant input such as authentication MUST be generated using a time-variant input such as
timestamps, sequence numbers, nonces, or a combination of these so timestamps, sequence numbers, nonces, or a combination of these so
that any re-use of the authentication data can be detected as that any re-use of the authentication data can be detected as
invalid. TLS makes use of an 8 byte sequence number to protect invalid. TLS makes use of an 8 byte sequence number to protect
against replay. against replay.
skipping to change at page 13, line 20 skipping to change at page 12, line 12
In order to meet the requirements in this document TLS extensions MAY In order to meet the requirements in this document TLS extensions MAY
be used. For example, TLS extensions may be useful in providing be used. For example, TLS extensions may be useful in providing
certificate revocation information via the TLS OCSP extension (thus certificate revocation information via the TLS OCSP extension (thus
meeting the requirement in Section 4.5.1.3). meeting the requirement in Section 4.5.1.3).
4.2.1.4. Peer Identity Privacy 4.2.1.4. Peer Identity Privacy
A tunnel protocol MUST support peer privacy. This requires that the A tunnel protocol MUST support peer privacy. This requires that the
username and other attributes associated with the peer are not username and other attributes associated with the peer are not
transmitted in the clear or to an unauthenticated, unauthorized transmitted in the clear or to an unauthenticated, unauthorized
party. If applicable, the peer certificate is sent confidentially party. Peer identity protection provided by the tunnel method
(i.e. encrypted). applies to tunnel methods and inner method specific identities. If
applicable, the peer certificate is sent confidentially (i.e.
encrypted).
4.2.1.5. Session Resumption 4.2.1.5. Session Resumption
The tunnel method MUST support TLS session resumption as defined in The tunnel method MUST support TLS session resumption as defined in
[RFC5246]. The tunnel method MAY support other methods of session [RFC5246]. The tunnel method MAY support other methods of session
resumption such as those defined in [RFC5077]. resumption such as those defined in [RFC5077].
4.2.2. Fragmentation 4.2.2. Fragmentation
Tunnel establishment sometimes requires the exchange of information Tunnel establishment sometimes requires the exchange of information
that exceeds what can be carried in a single EAP message. In that exceeds what can be carried in a single EAP message. In
addition information carried within the tunnel may also exceed this addition information carried within the tunnel may also exceed this
limit. Therefore a tunnel method MUST support fragmentation and limit. Therefore a tunnel method MUST support fragmentation and
reassembly. reassembly.
4.2.3. Protection of Data External to Tunnel 4.2.3. Protection of Data External to Tunnel
An attacker in the middle can modify clear text values such as An attacker in the middle can modify clear text values such as
protocol version and type code information communicated outside the protocol version and type code information communicated outside the
TLS tunnel. If modification of this information can cause TLS tunnel. The tunnel method MUST provide implicit or explicit
protection of the protocol version and type code. If modification of
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 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.
skipping to change at page 15, line 12 skipping to change at page 14, line 12
separate result indication for intermediate and final result MUST be separate result indication for intermediate and final result MUST be
supported. 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. the user's language preference as indicated by RFC 4646 [RFC4646].
Note that in some cases, such as when transmitting error codes, it is
acceptable to exchange numeric codes that can be translated by the
client to support the particular local language. These numeric codes
are not subject internationalization during transmission.
4.4. EAP Channel Binding Requirements 4.4. EAP Channel Binding Requirements
The tunnel method MUST be capable of meeting EAP channel binding The tunnel method MUST be capable of meeting EAP channel binding
requirements described in [I-D.clancy-emu-chbind]. requirements described in [I-D.clancy-emu-chbind].
4.5. Requirements Associated with Carrying Username and Passwords 4.5. Requirements Associated with Carrying Username and Passwords
This section describes the requirements associated with tunneled This section describes the requirements associated with tunneled
password authentication. The password authentication mentioned here password authentication. The password authentication mentioned here
refers to user or machine authentication using a legacy password refers to user or machine authentication using a legacy password
database or verifier, such as LDAP, OTP, etc. These typically database or verifier, such as LDAP, OTP, etc. These typically
require the password in its original text form in order to require the password in its original text form in order to
authenticate the peer, hence they require the peer to send the clear authenticate the peer, hence they require the peer to send the clear
text user name and password to the EAP server. text user name and password to the EAP server.
4.5.1. Security 4.5.1. Security
Due to the fact that the EAP peer needs to send clear text password Many internal EAP methods have the peer send its password in the
to the EAP server to authenticate against the legacy user clear To the EAP server. Other methods (e.g. challenge-response
information, the security measures in the following sections MUST be methods) are vulnerable to attacks if an eavesdropper can intercept
met. the traffic. For any such methods, the security measures in the
following sections MUST be met.
4.5.1.1. Confidentiality and Integrity 4.5.1.1. Confidentiality and Integrity
The clear text password exchange MUST be integrity and The clear text password exchange MUST be integrity and
confidentiality protected. As long as the password exchange occurs confidentiality protected. As long as the password exchange occurs
inside an authenticated and encrypted tunnel, this requirement is inside an authenticated and encrypted tunnel, this requirement is
met. met.
4.5.1.2. Authentication of Server 4.5.1.2. Authentication of Server
skipping to change at page 16, line 14 skipping to change at page 15, line 20
mechanisms to check the revocation status of a credential. The mechanisms to check the revocation status of a credential. The
tunnel method SHOULD make use of Online Certificate Status Protocol tunnel method SHOULD make use of Online Certificate Status Protocol
(OCSP) [RFC2560] or Server-based Certificate Validation Protocol (OCSP) [RFC2560] or Server-based Certificate Validation Protocol
(SCVP) [RFC5055] to obtain the revocation status of the EAP server (SCVP) [RFC5055] to obtain the revocation status of the EAP server
certificate. certificate.
4.5.2. Internationalization 4.5.2. Internationalization
The password authentication exchange MUST support user names and The password authentication exchange MUST support user names and
passwords in international languages. It MUST support encoding of passwords in international languages. It MUST support encoding of
user name and password strings in UTF-8 [RFC3629] format. Any user name and password strings in UTF-8 [RFC3629] format. The method
strings sent by the server during the password exchange and intended MUST specify how username and password normalizations and/or
for display to the user MUST be sent in UTF-8 format and SHOULD be comparisons is performed in reference to SASLPrep [RFC4013] or Net-
able to be marked with language information and adapted to the user's UTF-8 [RFC5198].
language preference.
Any strings sent by the server intended for display to the user MUST
be sent in UTF-8 format and SHOULD be able to be marked with language
information and adapted to the user's language preference as
indicated by RFC 4646 [RFC4646]. Note that in some cases, such as
when transmitting error codes, it is acceptable to exchange numeric
codes that can be translated by the client to support the particular
local language. These numeric codes are not subject
internationalization during transmission.
4.5.3. Meta-data 4.5.3. Meta-data
The password authentication exchange MUST support additional The password authentication exchange SHOULD support additional
associated meta-data which can be used to indicate whether the associated meta-data which can be used to indicate whether the
authentication is for a user or a machine. This allows the EAP authentication is for a user or a machine. This allows the EAP
server and peer to request and negotiate authentication specifically server and peer to request and negotiate authentication specifically
for a user or machine. This is useful in the case of multiple inner for a user or machine. This is useful in the case of multiple inner
authentications where the user and machine both need to be authentications where the user and machine both need to be
authenticated. authenticated.
4.5.4. Password Change 4.5.4. Password Change
The password authentication exchange MUST support password change, as The password authentication exchange MUST support password change.
well as other other "housekeeping" functions required by some The exchange SHOULD be extensible to support other "housekeeping"
systems. functions, such as the management of PINs or other data, required by
some systems.
4.6. Requirements Associated with Carrying EAP Methods 4.6. Requirements Associated with Carrying EAP Methods
The tunnel method MUST be able to carry inner EAP methods without The tunnel method MUST be able to carry inner EAP methods without
modifying them. EAP methods MUST NOT be redefined inside the tunnel. modifying them. EAP methods MUST NOT be redefined inside the tunnel.
4.6.1. Method Negotiation 4.6.1. Method Negotiation
The tunnel method MUST support the protected negotiation of the inner The tunnel method MUST support the protected negotiation of the inner
EAP method. It MUST NOT allow the inner EAP method negotiation to be EAP method. It MUST NOT allow the inner EAP method negotiation to be
downgraded or manipulated by intermediaries. downgraded or manipulated by intermediaries.
4.6.2. Chained Methods 4.6.2. Chained Methods
The tunnel method MUST support the chaining of multiple EAP methods. The tunnel method SHOULD support the chaining of multiple EAP
The tunnel method MUST allow for the communication of intermediate methods. The tunnel method MUST allow for the communication of
result and verification of compound binding between executed inner intermediate result and verification of compound binding between
methods when chained methods are employed. executed inner methods when chained methods are employed.
4.6.3. Cryptographic Binding with the TLS Tunnel 4.6.3. Cryptographic Binding with the TLS Tunnel
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 on tunnel methods [TUNNEL-MITM].
Cryptographic bindings enable the complete prevention of tunnel MitM Cryptographic bindings enable the complete prevention of tunnel MitM
attacks without the need of additional security policies as long as attacks without the need of additional security policies as long as
the inner method derives keys and is not vulnerable to attacks the inner method derives keys and is not vulnerable to attacks
skipping to change at page 18, line 40 skipping to change at page 17, line 48
system leads to compromises in other parts of the system. system leads to compromises in other parts of the system.
4.6.4. Peer Initiated 4.6.4. Peer Initiated
The tunnel method SHOULD allow for the peer to initiate an inner EAP The tunnel method SHOULD allow for the peer to initiate an inner EAP
authentication in order to meet its policy requirements for authentication in order to meet its policy requirements for
authenticating the server. authenticating the server.
4.6.5. Method Meta-data 4.6.5. Method Meta-data
The tunnel method MUST allow for the communication of additional data The tunnel method SHOULD allow for the communication of additional
associated with an EAP method. This can be used to indicate whether data associated with an EAP method. This can be used to indicate
the authentication is for a user or a machine. This allows the EAP whether the authentication is for a user or a machine. This allows
server and peer to request and negotiate authentication specifically the EAP server and peer to request and negotiate authentication
for a user or machine. This is useful in the case of multiple inner specifically for a user or machine. This is useful in the case of
EAP authentications where the user and machine both need to be multiple inner EAP authentications where the user and machine both
authenticated. need to be authenticated.
5. IANA Considerations 5. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
6. Security 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 strong key material between EAP Peer and EAP Server and to generate strong key material
for use in protecting lower layer protocols. In addition the tunnel for use in protecting lower layer protocols. In addition the tunnel
skipping to change at page 20, line 32 skipping to change at page 19, line 40
or only weak key material, security policies must be enforced such or only weak key material, security policies must be enforced such
that the peer cannot execute the inner method with the same that the peer cannot execute the inner method with the same
credentials outside a protective tunnel or with an untrustworthy credentials outside a protective tunnel or with an untrustworthy
server. server.
6.3. Data External to Tunnel 6.3. Data External to Tunnel
The tunnel method will use data that is outside the TLS tunnel such The tunnel method will use data that is outside the TLS tunnel such
as the EAP type code or version numbers. If an attacker can as the EAP type code or version numbers. If an attacker can
compromise the protocol by modifying these values the tunnel method compromise the protocol by modifying these values the tunnel method
MUST protect this data from modification. MUST protect this data from modification. In some cases external
data may not need additional protection because it is implicitly
verified during the protocol operation.
6.4. Separation of TLS Tunnel and Inner Authentication Termination
Terminating the inner method at a different location than the outer
tunnel needs careful consideration. The inner method data may be
vulnerable to modification and eavesdropping between the server that
terminates the tunnel and the server that terminates the inner
method. For example if a clear text password is used then it may be
sent to the inner method server in a RADIUS password attribute which
uses weak encryption that may not be suitable protection for many
environments.
In some cases terminating the tunnel at a different location may make
it difficult for a peer to authenticate the server and trust it for
further communication. For example, if the TLS tunnel is terminated
by a different organization the peer needs to be able to authenticate
and authorize the tunnel server to handle secret credentials that it
shares with the home server that terminates the inner method. This
may not meet the security policy of many environments."
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.clancy-emu-chbind] [I-D.clancy-emu-chbind]
Clancy, C. and K. Hoeper, "Channel Binding Support for EAP Clancy, C. and K. Hoeper, "Channel Binding Support for EAP
Methods", draft-clancy-emu-chbind-04 (work in progress), Methods", draft-clancy-emu-chbind-04 (work in progress),
November 2008. November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
skipping to change at page 21, line 33 skipping to change at page 21, line 12
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008. RFC 5247, August 2008.
7.2. Informative References 7.2. Informative References
[I-D.ietf-nea-pb-tnc] [I-D.ietf-nea-pb-tnc]
Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC", Broker Protocol (PB) Compatible with TNC",
draft-ietf-nea-pb-tnc-04 (work in progress), April 2009. draft-ietf-nea-pb-tnc-05 (work in progress),
September 2009.
[I-D.mahy-eap-enrollment] [I-D.mahy-eap-enrollment]
Mahy, R., "An Extensible Authentication Protocol (EAP) Mahy, R., "An Extensible Authentication Protocol (EAP)
Enrollment Method", draft-mahy-eap-enrollment-01 (work in Enrollment Method", draft-mahy-eap-enrollment-01 (work in
progress), March 2006. progress), March 2006.
[KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail",
ICST QShine , August 2007. ICST QShine , August 2007.
[NIST SP 800-108] [NIST SP 800-108]
Chen, L., "Recommendation for Key Derivation Using Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions", Draft NIST Special Pseudorandom Functions", Draft NIST Special
Publication 800-108, April 2008. Publication 800-108, April 2008.
[NIST SP 800-120] [NIST SP 800-120]
Hoeper, K. and L. Chen, "Recommendation for EAP Methods Hoeper, K. and L. Chen, "Recommendation for EAP Methods
Used in Wireless Network Access Authentication", Draft Used in Wireless Network Access Authentication", NIST
NIST Special Publication 800-120, December 2008. Special Publication 800-120, September 2009.
[NIST SP 800-57] [NIST SP 800-57]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendation for Key Management - Part 1: General "Recommendation for Key Management - Part 1: General
(Revised)", NIST Special Publication 800-57, part 1, (Revised)", NIST Special Publication 800-57, part 1,
March 2007. March 2007.
[NIST SP 800-57p3] [NIST SP 800-57p3]
Barker, E., Burr, W., Jones, A., Polk, W., , S., and M. Barker, E., Burr, W., Jones, A., Polk, W., , S., and M.
Smid, "Recommendation for Key Management, Part 3 Smid, "Recommendation for Key Management, Part 3
Application-Specific Key Management Guidance", Draft NIST Application-Specific Key Management Guidance", Draft NIST
Special Publication 800-57,part 3, October 2008. Special Publication 800-57,part 3, October 2008.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
RFC 2246, January 1999. Authentication Protocol (PEAP) Specification",
August 2009.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
(TLS) Protocol Version 1.1", RFC 4346, April 2006. Languages", RFC 4646, September 2006.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851, Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007. May 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008. Requirements", RFC 5209, June 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[TUNNEL-MITM] [TUNNEL-MITM]
Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
skipping to change at page 23, line 27 skipping to change at page 23, line 15
o Added text to section 4.6 that states method must not be re- o Added text to section 4.6 that states method must not be re-
defined inside the tunnel. defined inside the tunnel.
o Editorial fixes o Editorial fixes
Appendix B. Changes from -02 Appendix B. Changes from -02
o Editorial Fixes o Editorial Fixes
o Clarified client authentication during tunnel establishment o Clarified client authentication during tunnel establishment
o Changed text so that the tunnel method MUST meet all MUST and o Changed text so that the tunnel method MUST meet all MUST and
SHOULD requirements relevant to EAP methods in RFCs 4962 and 5247 SHOULD requirements relevant to EAP methods in RFCs 4962 and 5247
Appendix C. changes from -03
o Resolution of open issues:
http://trac.tools.ietf.org/wg/emu/trac/report/9
o Revised section 2 to match other similar RFC(Issue 6)
o Cleaned up section 3.2 (issue 8)
o Clarified identity protection scope in section 3.4 and
4.2.1.4(issue 9)
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, Inc.
1301 E Algonquin Rd 1301 E Algonquin Rd
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Email: khoeper@motorola.com Email: khoeper@motorola.com
Stephen Hanna Stephen Hanna
Juniper Networks Juniper Networks
3 Beverly Road 3 Beverly Road
Bedford, MA 01730 Bedford, MA 01730
USA USA
Email: shanna@juniper.net Email: shanna@juniper.net
Hao Zhou Hao Zhou
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.
 End of changes. 48 change blocks. 
192 lines changed or deleted 203 lines changed or added

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