draft-ietf-emu-eaptunnel-req-07.txt   draft-ietf-emu-eaptunnel-req-08.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: December 26, 2010 Juniper Networks Expires: March 21, 2011 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
June 24, 2010 September 17, 2010
Requirements for a Tunnel Based EAP Method Requirements for a Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-07.txt draft-ietf-emu-eaptunnel-req-08.txt
Abstract Abstract
This memo defines the requirements for a tunnel-based Extensible This memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method. This method will use Transport Authentication Protocol (EAP) Method. This method will use Transport
Layer Security (TLS) to establish a secure tunnel. The tunnel will Layer Security (TLS) to establish a secure tunnel. The tunnel will
provide support for password authentication, EAP authentication and provide support for password authentication, EAP authentication and
the transport of additional data for other purposes. the transport of additional data for other purposes.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2010. This Internet-Draft will expire on March 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 32 skipping to change at page 4, line 32
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 Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Running EAP methods within a TLS protected tunnel has been deployed Running EAP methods within a TLS protected tunnel has been deployed
in several different solutions. EAP methods supporting this include in several different solutions. EAP methods supporting this include
PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this PEAP [PEAP], TTLS [RFC5281] and EAP-FAST [RFC4851]. In general this
has worked well so there is consensus to continue to use TLS as the has worked well so there is consensus to continue to use TLS as the
basis for a tunnel method. There have been various reasons for basis for a tunnel method. There have been various reasons for
employing a protected tunnel for EAP processes. They include employing a protected tunnel for EAP processes. They include
protecting weak authentication exchanges, such as username and protecting weak authentication exchanges, such as username and
skipping to change at page 6, line 20 skipping to change at page 6, line 20
where the authentication server does not have access to the cleartext where the authentication server does not have access to the cleartext
password or a consistent transform of the cleartext password. password or a consistent transform of the cleartext password.
Example of such systems are one time password (OTP) systems and other Example of such systems are one time password (OTP) systems and other
systems where the username and password are submitted to an external systems where the username and password are submitted to an external
party for validation. The tunnel method MUST support transporting party for validation. The tunnel method MUST support transporting
cleartext username and password to the EAP server. It MUST NOT cleartext username and password to the EAP server. It MUST NOT
reveal information about the username and password to parties in the reveal information about the username and password to parties in the
communication path between the peer and the EAP Server. The communication path between the peer and the EAP Server. The
advantage any attacker gains against the tunneled method when advantage any attacker gains against the tunneled method when
employing a username and password for authentication MUST be through employing a username and password for authentication MUST be through
interaction and not computation. The tunnel MUST provide protection interaction and not computation. The tunnel MUST support protection
from man-in-the-middle attacks. The combination of the tunnel from man-in-the-middle attacks. The combination of the tunnel
authentication and password authentication MUST enable mutual 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
skipping to change at page 6, line 50 skipping to change at page 6, line 50
the inner method executed within the tunnel. When weak methods are the inner method executed within the tunnel. When weak methods are
used, these attacks can be mitigated via security policies that used, these attacks can be mitigated via security policies that
require the method to be used only within a tunnel. On the other require the method to be used only within a tunnel. On the other
hand, a technical solution (so-called cryptographic bindings) can be hand, a technical solution (so-called cryptographic bindings) can be
used whenever the inner method derives key material and is not used whenever the inner method derives key material and is not
susceptible to attacks outside a tunnel. Only the latter mitigation susceptible to attacks outside a tunnel. 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] and [LCN 2010] for a discussion on
policies and complete solutions for thwarting tunnel MitM attacks. security 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
skipping to change at page 16, line 39 skipping to change at page 16, line 39
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
outside a protected tunnel [KHLC07]. Even though weak or non-key outside a protected tunnel [LCN 2010]. Even though weak or non-key
deriving inner methods may be permitted, and thus security policies deriving inner methods may be permitted, and thus security policies
preventing tunnel MitM attacks are still necessary, the tunnel method preventing tunnel MitM attacks are still necessary, the tunnel method
MUST provide cryptographic bindings, because only this allows MUST provide cryptographic bindings, because only this allows
migrating to more secure, policy-independent implementations. migrating to more secure, policy-independent implementations.
Cryptographic bindings are typically achieved by securely mixing the Cryptographic bindings are typically achieved by securely mixing the
established keying material (say tunnel key TK) from the tunnel established keying material (say tunnel key TK) from the tunnel
protocol with the established keying material (say method key MK) protocol with the established keying material (say method key MK)
from the inner authentication method(s) in order to derive fresh from the inner authentication method(s) in order to derive fresh
keying material. If chained EAP methods are executed in the tunnel, keying material. If chained EAP methods are executed in the tunnel,
skipping to change at page 17, line 40 skipping to change at page 17, line 40
---------------- ----------------
| | | | | |
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 be derived in accordance to the guidelines for key derivations SHOULD follow the recommendations for key derivations and key
and key hierarchies as specified in Section 4.2.1.1.3. In hierarchies as specified in [NIST SP 800-108]. In particular, all
particular, all derived keys MUST have a lifetime assigned that does derived keys MUST have a lifetime assigned that does not exceed the
not exceed the lifetime of any key higher in the key hierarchy. The lifetime of any key higher in the key hierarchy. The derivation MUST
derivation MUST prevent a compromise in one part of the system from prevent a compromise in one part of the system from leading to
leading to compromises in other parts of the system that relay on compromises in other parts of the system that relay on keys at the
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
The tunnel method SHOULD allow for the peer to initiate an inner EAP The tunnel method SHOULD allow for the peer to initiate an inner EAP
authentication in order to meet its policy requirements for authentication in order to meet its policy requirements for
authenticating the server. authenticating the server.
4.6.5. Method Meta-data 4.6.5. Method Meta-data
The tunnel method SHOULD allow for the communication of additional The tunnel method SHOULD allow for the communication of additional
skipping to change at page 21, line 26 skipping to change at page 21, line 26
7.2. Informative References 7.2. Informative References
[I-D.mahy-eap-enrollment] [I-D.mahy-eap-enrollment]
Mahy, R., "An Extensible Authentication Protocol (EAP) Mahy, R., "An Extensible Authentication Protocol (EAP)
Enrollment Method", draft-mahy-eap-enrollment-01 (work in Enrollment Method", draft-mahy-eap-enrollment-01 (work in
progress), March 2006. progress), March 2006.
[KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail",
ICST QShine , August 2007. ICST QShine , August 2007.
[LCN 2010]
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] [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", NIST Used in Wireless Network Access Authentication", NIST
Special Publication 800-120, September 2009. Special Publication 800-120, September 2009.
 End of changes. 10 change blocks. 
16 lines changed or deleted 23 lines changed or added

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