< draft-nir-tls-eap-02.txt		draft-nir-tls-eap-03.txt >
	TLS Working Group Y. Nir		TLS Working Group Y. Nir
	Internet-Draft Y. Sheffer		Internet-Draft Y. Sheffer
	Intended status: Standards Track Check Point		Intended status: Standards Track Check Point
	Expires: April 16, 2008 H. Tschofenig		Expires: October 6, 2008 H. Tschofenig
	NSN		NSN
	P. Gutmann		P. Gutmann
	University of Auckland		University of Auckland
	October 14, 2007		April 4, 2008
	TLS using EAP Authentication		TLS using EAP Authentication
	draft-nir-tls-eap-02.txt		draft-nir-tls-eap-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 April 16, 2008.		This Internet-Draft will expire on October 6, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document describes an extension to the TLS protocol to allow TLS		This document describes an extension to the TLS protocol to allow TLS
	clients to authenticate with legacy credentials using the Extensible		clients to authenticate with legacy credentials using the Extensible
	Authentication Protocol (EAP).		Authentication Protocol (EAP).
	This work follows the example of IKEv2, where EAP has been added to		This work follows the example of IKEv2, where EAP has been added to
	the IKEv2 protocol to allow clients to use different credentials such		the IKEv2 protocol to allow clients to use different credentials such
	as passwords, token cards, and shared secrets.		as passwords, token cards, and shared secrets.
	When TLS is used with EAP, additional records are sent after the		When TLS is used with EAP, additional records are sent after the
	ChangeCipherSpec protocol message and before the Finished message,		ChangeCipherSpec protocol message and before the Finished message,
	effectively creating an extended handshake before the application		effectively creating an extended handshake before the application
	layer data can be sent. Each EapMsg handshake record contains		layer data can be sent. Each EapMsg handshake record contains
	exactly one EAP message. Using EAP for client authentication allows		exactly one EAP message. Using EAP for client authentication allows
	TLS to be used with various AAA back-end servers, such as RADIUS or		TLS to be used with various AAA back-end servers such as RADIUS or
	Diameter.		Diameter.
	TLS with EAP may be used for securing a data connection such as HTTP		TLS with EAP may be used for securing a data connection such as HTTP
	or POP3. We believe it has three main benefits:		or POP3. We believe it has three main benefits:
	o The ability of EAP to work with backend servers can remove that		o The ability of EAP to work with backend servers can remove that
	burden from the application layer.		burden from the application layer.
	o Moving the user authentication into the TLS handshake protects the		o Moving the user authentication into the TLS handshake protects the
	presumably less secure application layer from attacks by		presumably less secure application layer from attacks by
	unauthenticated parties.		unauthenticated parties.
	o Using mutual authentication methods within EAP can help thwart		o Using mutual authentication methods within EAP can help thwart
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8		3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8
	3.4. Calculating the Finished message . . . . . . . . . . . . . 9		3.4. Calculating the Finished message . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10		4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
	4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10		4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10
	4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11		4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11
	5. Performance Considerations . . . . . . . . . . . . . . . . . . 12		5. Performance Considerations . . . . . . . . . . . . . . . . . . 12
	6. Operational Considerations . . . . . . . . . . . . . . . . . . 13		6. Operational Considerations . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17		9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . . 17		9.3. Changes from the protocol model draft . . . . . . . . . . 16
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19		10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
	A.1. Changes from Previous Versions . . . . . . . . . . . . . . 19		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	A.1.1. Changes in version -02 . . . . . . . . . . . . . . . . 19		11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	A.1.2. Changes in version -01 . . . . . . . . . . . . . . . . 19		11.2. Informative References . . . . . . . . . . . . . . . . . . 18
	A.1.3. Changes from the protocol model draft . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . . . 21		Intellectual Property and Copyright Statements . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document describes a new extension to [TLS] that allows a TLS		This document describes a new extension to [TLS]. This extension
	client to authenticate using [EAP] instead of performing the		allows a TLS client to authenticate using [EAP] instead of performing
	authentication at the application layer. The extension follows		the authentication at the application level. The extension follows
	[TLS-EXT]. For the remainder of this document we will refer to this		[TLS-EXT]. For the remainder of this document we will refer to this
	extension as TEE (TLS with EAP Extension).		extension as TEE (TLS with EAP Extension).
	TEE extends the TLS handshake beyond the regular setup, to allow the		TEE extends the TLS handshake beyond the regular setup, to allow the
	EAP protocol to run between the TLS server (called an "authenticator"		EAP protocol to run between the TLS server (called an "authenticator"
	in EAP) and the TLS client (called a "supplicant"). This allows the		in EAP) and the TLS client (called a "supplicant"). This allows the
	TLS architecture to handle client authentication before exposing the		TLS architecture to handle client authentication before exposing the
	server application software to an unauthenticated client. In doing		server application software to an unauthenticated client. In doing
	this, we follow the approach taken for IKEv2 in [RFC4306]. However,		this, we follow the approach taken for IKEv2 in [RFC4306]. However,
	similar to regular TLS, we protect the user identity by only sending		similar to regular TLS, we protect the user identity by only sending
	the client identity after the server has authenticated. In this our		the client identity after the server has authenticated. In this our
	solution differs from that of IKEv2.		solution differs from that of IKEv2.
	Today, most applications that rely on symmetric credentials use TLS		Currently used applications that rely on non-certificate user
	to authenticate the server only. After that, the application takes		credentials use TLS to authenticate the server only. After that, the
	over, and presents a login screen where the user is expected to		application takes over, and presents a login screen where the user is
	present their credentials.		expected to present their credentials.
	This creates several problems. It allows a client to access the		This creates several problems. It allows a client to access the
	application before authentication, thus creating a potential for		application before authentication, thus creating a potential for
	anonymous attacks on non-hardened applications. Additionally, web		anonymous attacks on non-hardened applications. Additionally, web
	pages are not particularly well suited for long shared secrets and		pages are not particularly well suited for long shared secrets and
	for interfacing with certain devices such as USB tokens.		for interfacing with certain devices such as USB tokens.
	TEE allows full mutual authentication to occur for all these		TEE allows full mutual authentication to occur for all these
	applications within the TLS exchange. The application receives		applications within the TLS exchange. The application receives
	control only when the user is identified and authenticated. The		control only when the user is identified and authenticated. The
	authentication can be built into the server infrastructure by		authentication can be built into the server infrastructure by
	connecting to a AAA server. The client side can be integrated into		connecting to an AAA server. The client side can be integrated into
	client software such as web browsers and mail clients. An EAP		client software such as web browsers and mail clients. An EAP
	infrastructure is already built into major operating systems		infrastructure is already built into some operating systems providing
	providing a user interface for each authentication method within EAP.		a user interface for each authentication method within EAP.
	We intend TEE to be used for various protocols that use TLS such as		We intend TEE to be used for various protocols that use TLS such as
	HTTPS, in cases where certificate based client authentication is not		HTTPS, in cases where certificate based client authentication is not
	practical. This includes web-based mail services, online banking,		practical. This includes web-based mail services, online banking,
	premium content websites and mail clients.		premium content websites and mail clients.
	Another class of applications that may see benefit from TEE are TLS		Another class of applications that may see benefit from TEE are TLS
	based VPN clients used as part of so-called "SSL VPN" products. No		based VPN clients used as part of so-called "SSL VPN" products. No
	such client protocols so far has been standardized.		such client protocols have so far been standardized.
	1.1. EAP Applicability		1.1. EAP Applicability
	Section 1.3 of [EAP] states that EAP is only applicable for network		Section 1.3 of [EAP] states that EAP is only applicable for network
	access authentication, rather than for "bulk data transfer". It then		access authentication, rather than for "bulk data transfer". It then
	goes on to explain why the transport properties of EAP indeed make it		goes on to explain why the transport properties of EAP indeed make it
	unsuitable for bulk data transfer, e.g., for large file transport.		unsuitable for bulk data transfer, e.g. for large file transport.
	Our proposed use of EAP falls squarely within the applicability as		Our proposed use of EAP falls squarely within the applicability as
	defined, since we make no further use of EAP beyond access		defined, since we make no further use of EAP beyond access
	authentication.		authentication.
	1.2. Comparison with Design Alternatives		1.2. Comparison with Design Alternatives
	It has been suggested to implement EAP authentication as part of the		It has been suggested to implement EAP authentication as part of the
	protected application, rather than as part of the TLS handshake. A		protected application, rather than as part of the TLS handshake. A
	BCP document could be used to describe a secure way of doing this.		BCP document could be used to describe a secure way of doing this.
	The drawbacks we see in such an approach are listed below:		The drawbacks we see in such an approach are listed below:
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	designers would need to specify an EAP transport for each		designers would need to specify an EAP transport for each
	application. Making this a part of TLS has the benefit of a		application. Making this a part of TLS has the benefit of a
	single specification for all protected applications.		single specification for all protected applications.
	o The integration of EAP and TLS is security-sensitive and should be		o The integration of EAP and TLS is security-sensitive and should be
	standardized and interoperable. We do not believe that it should		standardized and interoperable. We do not believe that it should
	be left to application designers to do this in a secure manner.		be left to application designers to do this in a secure manner.
	Specifically on the server-side, integration with AAA servers adds		Specifically on the server-side, integration with AAA servers adds
	complexity and is more naturally part of the underlying		complexity and is more naturally part of the underlying
	infrastrcture.		infrastrcture.
	o Our current proposal provides channel binding between TLS and EAP,		o Our current proposal provides channel binding between TLS and EAP,
	to counter the MITM attacks described in [MITM]. A draft for		to counter the MITM attacks described in [MITM]. TLS does not
	allowing applications the access to keying material produced by		provide any standard way of extracting cryptographic material from
	TLS is available with [I-D.rescorla-tls-extractor]. This type of		the TLS state, and in most implementations, the TLS state is not
	interworking between the TLS stack and the application layer is		exposed to the protected application. Because of this, it is
	necessary when EAP is run outside the TLS handshake and then the		difficult for application designers to bind the user
	two exchanges need to be linked together. Since the key extractor		authentication to the protected channel provided by TLS.
	functionality is not yet available in TLS stacks it is difficult
	for application designers to bind the user authentication to the
	protected channel provided by TLS.
	1.3. Conventions Used in This Document		1.3. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Operating Environment		2. Operating Environment
	TEE will work between a client application and a server application,		TEE will work between a client application and a server application,
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	The client indicates in the first message its support for TEE. The		The client indicates in the first message its support for TEE. The
	server sends an EAP identity request in the reply. The client sends		server sends an EAP identity request in the reply. The client sends
	the identity reply after the handshake completion. The EAP request-		the identity reply after the handshake completion. The EAP request-
	response sequence continues until the client is either authenticated		response sequence continues until the client is either authenticated
	or rejected.		or rejected.
	3.1. The tee_supported Extension		3.1. The tee_supported Extension
	The tee_supported extension is a ClientHello and ServerHello		The tee_supported extension is a ClientHello and ServerHello
	extension as defined in Section 2.3 of [TLS-EXT]. The extension_type		extension as defined in section 2.3 of [TLS-EXT]. The extension_type
	field is TBA by IANA. The extension_data is zero-length.		field is TBA by IANA. The extension_data is zero-length.
	3.2. The InterimAuth Handshake Message		3.2. The InterimAuth Handshake Message
	The InterimAuth message is identical in syntax to the Finished		The InterimAuth message is identical in syntax to the Finished
	message described in Section 7.4.9 of [TLS]. It is calculated in		message described in section 7.4.9 of [TLS]. It is calculated in
	exactly the same way.		exactly the same way.
	The semantics, however, are somewhat different. The "Finished"		The semantics, however, are somewhat different. The "Finished"
	message indicates that application data may now be sent. The		message indicates that application data may now be sent. The
	"InterimAuth" message does not indicate this. Instead, further		"InterimAuth" message does not indicate this. Instead, further
	handshake messages are needed.		handshake messages are needed.
	The HandshakeType value for the InterimAuth handshake message is TBA		The HandshakeType value for the InterimAuth handshake message is TBA
	by IANA.		by IANA.
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 42 ¶
	IANA.		IANA.
	The EapMsg message is used to tunnel EAP messages between the		The EapMsg message is used to tunnel EAP messages between the
	authentication server, which may be co-located with the TLS server,		authentication server, which may be co-located with the TLS server,
	or else may be a separate AAA server, and the supplicant, which is		or else may be a separate AAA server, and the supplicant, which is
	co-located with the TLS client. TLS on either side receives the EAP		co-located with the TLS client. TLS on either side receives the EAP
	data from the EAP infrastructure, and treats it as opaque. TLS does		data from the EAP infrastructure, and treats it as opaque. TLS does
	not make any changes to the EAP payload or make any decisions based		not make any changes to the EAP payload or make any decisions based
	on the contents of an EapMsg handshake message.		on the contents of an EapMsg handshake message.
	Note that it is expected that the EAP server notifies the TLS server		Note that it is expected that the authentication server notifies the
	about authentication success or failure, and TLS does not inspect the		TLS server about authentication success or failure, and so TLS need
	eap_payload within the EapMsg to detect success or failure.		not inspect the eap_payload within the EapMsg to detect success or
			failure.
	struct {		struct {
	opaque eap_payload[4..65535];		opaque eap_payload[4..65535];
	} EapMsg;		} EapMsg;
	eap_payload is defined in section 4 of RFC 3748. It includes		eap_payload is defined in section 4 of RFC 3748. It includes
	the Code, Identifier, Length and Data fields of the EAP		the Code, Identifier, Length and Data fields of the EAP
	packet.		packet.
	3.4. Calculating the Finished message		3.4. Calculating the Finished message
	skipping to change at page 9, line 19 ¶		skipping to change at page 9, line 26 ¶
	Finished message is calculated as follows:		Finished message is calculated as follows:
	struct {		struct {
	opaque verify_data[12];		opaque verify_data[12];
	} Finished;		} Finished;
	verify_data		verify_data
	PRF(MSK, finished_label, MD5(handshake_messages) +		PRF(MSK, finished_label, MD5(handshake_messages) +
	SHA-1(handshake_messages)) [0..11];		SHA-1(handshake_messages)) [0..11];
	The finished_label and the PRF are as defined in Section 7.4.9 of		The finished_label and the PRF are as defined in section 7.4.9 of
	[TLS].		[TLS].
	The handshake_messages field, unlike regular TLS, does not sign all		The handshake_messages field, unlike regular TLS, does not sign all
	the data in the handshake. Instead it signs all the data that has		the data in the handshake. Instead it signs all the data that has
	not been signed by the previous InterimAuth message. The		not been signed by the previous InterimAuth message. The
	handshake_messages field includes all of the octets beginning with		handshake_messages field includes all of the octets beginning with
	and including the InterimAuth message, up to but not including this		and including the InterimAuth message, up to but not including this
	Finished message. This is the concatenation of all the Handshake		Finished message. This is the concatenation of all the Handshake
	structures exchanged thus far, and not yet signed, as defined in		structures exchanged thus far, and not yet signed, as defined in
	Section 7.4 of [TLS]and in this document.		section 7.4 of [TLS]and in this document.
	The Master Session Key (MSK) is derived by the AAA server and by the		The Master Session Key (MSK) is derived by the AAA server and by the
	client if the EAP method is key-generating. On the server-side, it		client if the EAP method is key-generating. On the server-side, it
	is typically received from the AAA server over the RADIUS or Diameter		is typically received from the AAA server over the RADIUS or Diameter
	protocol. On the client-side, it is passed to TLS by some other		protocol. On the client-side, it is passed to TLS by some other
	method.		method.
	If the EAP method is not key-generating, then the master_secret is		If the EAP method is not key-generating, then the master_secret is
	used to sign the messages instead of the MSK. For a discussion on		used to sign the messages instead of the MSK. For a discussion on
	the use of such methods, see Section 4.1.		the use of such methods, see Section 4.1.
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 44 ¶
	It should be noted that using non-key-generating methods may expose		It should be noted that using non-key-generating methods may expose
	the client to a MITM attack if the same method and credentials are		the client to a MITM attack if the same method and credentials are
	used in some other situation, in which the EAP is done outside of a		used in some other situation, in which the EAP is done outside of a
	protected tunnel with an authenticated server. Unless it can be		protected tunnel with an authenticated server. Unless it can be
	determined that the EAP method is never used in such a situation,		determined that the EAP method is never used in such a situation,
	non-key-generating methods SHOULD NOT be used. This issue is		non-key-generating methods SHOULD NOT be used. This issue is
	discussed extensively in [Compound-Authentication].		discussed extensively in [Compound-Authentication].
	4.2. Identity Protection		4.2. Identity Protection
	Unlike [TLS-PSK], TEE provides active user identity confidentiality		Unlike [TLS-PSK], TEE provides identity protection for the client.
	for the client. The client's identity is hidden from an active and a		The client's identity is hidden from a passive eavesdropper using TLS
	passive eavesdropper using the server-side authenticated TLS channel		encryption. Active attacks are discussed in Section 4.3.
	(followed by encryption of the EAP-based handshake messages). Active
	attacks are discussed in Section 4.3.
	We could save one round-trip by having the client send its identity		We could save one round-trip by having the client send its identity
	within the Client Hello message. This is similar to TLS-PSK.		within the Client Hello message. This is similar to TLS-PSK.
	However, we believe that identity protection is a worthy enough goal,		However, we believe that identity protection is a worthy enough goal,
	so as to justify the extra round-trip.		so as to justify the extra round-trip.
	4.3. Mutual Authentication		4.3. Mutual Authentication
	In order to achieve our security goals, we need to have both the		In order to achieve our security goals, we need to have both the
	server and the client authenticate. Client authentication is		server and the client authenticate. Client authentication is
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	The TLS Inner Application Extension work ([TLS/IA]) has inspired the		The TLS Inner Application Extension work ([TLS/IA]) has inspired the
	authors to create this simplified work. TLS/IA provides a somewhat		authors to create this simplified work. TLS/IA provides a somewhat
	different approach to integrating non-certificate credentials into		different approach to integrating non-certificate credentials into
	the TLS protocol, in addition to several other features available		the TLS protocol, in addition to several other features available
	from the RADIUS namespace.		from the RADIUS namespace.
	The authors would also like to thank the various contributors to		The authors would also like to thank the various contributors to
	[RFC4306] whose work inspired this one.		[RFC4306] whose work inspired this one.
	9. Open Issues		9. Changes from Previous Versions
			9.1. Changes in version -02
			o Added discussion of alternative designs.
			9.2. Changes in version -01
			o Changed the construction of the Finished message
			o Replaced MS-CHAPv2 with GPSK in examples.
			o Added open issues section.
			o Added reference to [Compound-Authentication]
			o Fixed reference to MITM attack
			9.3. Changes from the protocol model draft
			o Added diagram for EapMsg
			o Added discussion of EAP applicability
			o Added discussion of mutually-authenticated EAP methods vs other
			methods in the security considerations.
			o Added operational considerations.
			o Other minor nits.
			10. Open Issues
	Some have suggested that since the protocol is identical to regular		Some have suggested that since the protocol is identical to regular
	TLS up to the InterimAuth message, we should call that the Finished		TLS up to the InterimAuth message, we should call that the Finished
	message, and call the last message in the extended handshake		message, and call the last message in the extended handshake
	something like "EapFinished". This has the advantage that the		something like "EapFinished". This has the advantage that the
	construction of Finished is already well defined and will not change.		construction of Finished is already well defined and will not change.
	However, the Finished message has a specific meaning as indicated by		However, the Finished message has a specific meaning as indicated by
	its name. It means that the handshake is over and that application		its name. It means that the handshake is over and that application
	data can now be sent. This is not true of what is in this draft		data can now be sent. This is not true of what is in this draft
	called InterimAuth. We would like the opinions of reviewers about		called InterimAuth. We'd like the opinions of reviewrs about this
	this issue.		issue.
	The MSK from the EAP exchange is only used to sign the Finished		The MSK from the EAP exchange is only used to sign the Finished
	message. It is not used again in the data encryption. In this we		message. It is not used again in the data encryption. In this we
	followed the example of IKEv2. The reason is that TLS already has		followed the example of IKEv2. The reason is that TLS already has
	perfectly good ways of exchanging keys, and we do not need this		perfectly good ways of exchanging keys, and we do not need this
	capability from EAP methods. Also, using the MSK in keys would		capability from EAP methods. Also, using the MSK in keys would
	require an additional ChangeCipherSpec and would complicate the		require an additional ChangeCipherSpec and would complicate the
	protocol. We would like the opinions of reviewers about this issue.		protocol. We'd like the opinions of reviewrs about this issue.
	Another response we got was that we should have a MUST requirement		Another response we got was that we should have a MUST requirement
	that only mutually authenticated and key generating methods be used		that only mutually authenticated and key-generating methods be used
	in TEE. This would simplify the security considerations section.		in TEE. This would simplify the security considerations section.
	While we agree that this is a good idea, most EAP methods in common		While we agree that this is a good idea, most EAP methods in common
	use are not compliant. Additionally, such requirements assume that		use are not compliant. Additionally, such requirements assume that
	EAP packets are visible to a passive attacker. As EAP is used in		EAP packets are visible to a passive attacker. As EAP is used in
	protected tunnels such as in L2TP, in IKEv2 and here, this assumption		protected tunnels such as in L2TP, in IKEv2 and here, this assumption
	may not be required. If we consider the server authenticated by its		may not be required. If we consider the server authenticated by its
	certificate, it may be acceptable to use a non-MA method.		certificate, it may be acceptable to use a non-MA method.
	It has been suggested that identity protection is not important		It has been suggested that identity protection is not important
	enough to add a roundtrip, and so we should have the client send the		enough to add a roundtrip, and so we should have the client send the
	username in the ClientHello. We are not sure about how others feel		username in the ClientHello. We are not sure about how others feel
	about this, and would like to solicit the reviewers opinion. Note		about this, and would like to solicit the reviewers opinion. Note
	that if this is done, the client sends the user name before ever		that if this is done, the client sends the user name before ever
	receiving any indication that the server actually supports TEE. This		receiving any indication that the server actually supports TEE. This
	might be acceptable in an email client, where the server is		might be acceptable in an email client, where the server is
	preconfigured, but it may be unacceptable in other uses, such as web		preconfigured, but it may be unacceptable in other uses, such as web
	browsers.		browsers.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[EAP] 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.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,		[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
	and T. Wright, "Transport Layer Security (TLS)		and T. Wright, "Transport Layer Security (TLS)
	Extensions", RFC 4366, April 2006.		Extensions", RFC 4366, April 2006.
	10.2. Informative References		11.2. Informative References
	[Compound-Authentication]		[Compound-Authentication]
	Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,		Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
	"The Compound Authentication Binding Problem",		"The Compound Authentication Binding Problem",
	draft-puthenkulam-eap-binding-04 (work in progress),		draft-puthenkulam-eap-binding-04 (work in progress),
	October 2003.		October 2003.
	[Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[Dia-EAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application", RFC 4072,		Authentication Protocol (EAP) Application", RFC 4072,
	August 2005.		August 2005.
	skipping to change at page 17, line 49 ¶		skipping to change at page 18, line 49 ¶
	[EAP-GPSK]		[EAP-GPSK]
	Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared		Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
	Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in		Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in
	progress), April 2007.		progress), April 2007.
	[I-D.ietf-eap-keying]		[I-D.ietf-eap-keying]
	Aboba, B., "Extensible Authentication Protocol (EAP) Key		Aboba, B., "Extensible Authentication Protocol (EAP) Key
	Management Framework", draft-ietf-eap-keying-18 (work in		Management Framework", draft-ietf-eap-keying-18 (work in
	progress), February 2007.		progress), February 2007.
	[I-D.rescorla-tls-extractor]
	Rescorla, E., "Keying Material Extractors for Transport
	Layer Security (TLS)", draft-rescorla-tls-extractor-00
	(work in progress), January 2007.
	[I.D.Webauth-phishing]		[I.D.Webauth-phishing]
	Hartman, S., "Requirements for Web Authentication		Hartman, S., "Requirements for Web Authentication
	Resistant to Phishing", draft-hartman-webauth-phishing-03		Resistant to Phishing", draft-hartman-webauth-phishing-03
	(work in progress), March 2007.		(work in progress), March 2007.
	[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle		[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
	in Tunneled Authentication Protocols", IACR ePrint		in Tunneled Authentication Protocols", IACR ePrint
	Archive , October 2002.		Archive , October 2002.
	[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication		[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
	skipping to change at page 19, line 5 ¶		skipping to change at page 20, line 5 ¶
	[TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites		[TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
	for Transport Layer Security (TLS)", RFC 4279,		for Transport Layer Security (TLS)", RFC 4279,
	December 2005.		December 2005.
	[TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and		[TLS/IA] Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
	T. Hardjono, "TLS Inner Application Extension (TLS/IA)",		T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
	draft-funk-tls-inner-application-extension-03 (work in		draft-funk-tls-inner-application-extension-03 (work in
	progress), June 2006.		progress), June 2006.
	Appendix A. Change History
	A.1. Changes from Previous Versions
	A.1.1. Changes in version -02
	o Added discussion of alternative designs.
	A.1.2. Changes in version -01
	o Changed the construction of the Finished message
	o Replaced MS-CHAPv2 with GPSK in examples.
	o Added open issues section.
	o Added reference to [Compound-Authentication]
	o Fixed reference to MITM attack
	A.1.3. Changes from the protocol model draft
	o Added diagram for EapMsg
	o Added discussion of EAP applicability
	o Added discussion of mutually-authenticated EAP methods vs other
	methods in the security considerations.
	o Added operational considerations.
	o Other minor nits.
	Authors' Addresses		Authors' Addresses
	Yoav Nir		Yoav Nir
	Check Point Software Technologies Ltd.		Check Point Software Technologies Ltd.
	5 Hasolelim st.		5 Hasolelim st.
	Tel Aviv 67897		Tel Aviv 67897
	Israel		Israel
	Email: ynir@checkpoint.com		Email: ynir@checkpoint.com
	Yaron Sheffer		Yaron Sheffer
	Check Point Software Technologies Ltd.		Check Point Software Technologies Ltd.
	5 Hasolelim st.		5 Hasolelim st.
	Tel Aviv 67897		Tel Aviv 67897
	Israel		Israel
	Email: yaronf@checkpoint.com		Email: yaronf at checkpoint dot com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Peter Gutmann		Peter Gutmann
	University of Auckland		University of Auckland
	Department of Computer Science		Department of Computer Science
	New Zealand		New Zealand
	Email: pgut001@cs.auckland.ac.nz		Email: pgut001@cs.auckland.ac.nz
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 31 change blocks.
	88 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/