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/