< draft-nir-tls-eap-11.txt		draft-nir-tls-eap-12.txt >
	TLS Working Group Y. Nir		TLS Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Standards Track Y. Sheffer		Intended status: Standards Track Y. Sheffer
	Expires: September 11, 2011 Independent		Expires: December 25, 2011 Independent
	H. Tschofenig		H. Tschofenig
	NSN		NSN
	P. Gutmann		P. Gutmann
	University of Auckland		University of Auckland
	March 10, 2011		June 23, 2011
	TLS using EAP Authentication		A Flexible Authentication Framework for the Transport Layer Security
	draft-nir-tls-eap-11		(TLS) Protocol using the Extensible Authentication Protocol (EAP)
			draft-nir-tls-eap-12
	Abstract		Abstract
	This document describes an extension to the TLS protocol to allow TLS		Many of today's Web security problems have their root in the
	clients to authenticate with non-certificate credentials using the		widespread usage of weak authentication mechanisms bundled with the
	Extensible Authentication Protocol (EAP).		usage of password based credentials. Dealing with both of these
			problems is the basis of this publication.
			This document extends the Transport Layer Security (TLS) protocol
			with a flexible and widely deployed authentication framework, namely
			the Extensible Authentication Protocol (EAP), to improve security of
			Web- as well as non-Web-based applications. The EAP framework allows
			so-called EAP methods, i.e. authentication and key exchange
			protocols, to be plugged into EAP without having to re-design the
			underlying protocol. The benefit of such an easy integration is the
			ability to run authentication protocols that fit a specific
			deployment environment, both from a credential choice as well as from
			the security and performance characteristics of the actual protocol.
	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 protocol to allow clients to use different credentials such as		allow clients to seamlessly use different forms of authentication
	passwords, token cards, and shared secrets.		credentials, such as passwords, token cards, and shared secrets.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 11, 2011.		This Internet-Draft will expire on December 25, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 4		1.1. EAP Applicability . . . . . . . . . . . . . . . . . . . . 5
	1.2. Comparison with Design Alternatives . . . . . . . . . . . 4		1.2. Comparison with Design Alternatives . . . . . . . . . . . 5
	1.3. Conventions Used in This Document . . . . . . . . . . . . 4		1.3. Conventions Used in This Document . . . . . . . . . . . . 5
	2. Operating Environment . . . . . . . . . . . . . . . . . . . . 5		2. Operating Environment . . . . . . . . . . . . . . . . . . . . 6
	3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6		3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. The tee_supported Extension . . . . . . . . . . . . . . . 7		3.1. The tee_supported Extension . . . . . . . . . . . . . . . 8
	3.2. The InterimAuth Handshake Message . . . . . . . . . . . . 7		3.2. The EapFinished Handshake Message . . . . . . . . . . . . 8
	3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 8		3.3. The EapMsg Handshake Message . . . . . . . . . . . . . . . 9
	3.4. Calculating the Finished message . . . . . . . . . . . . . 8		3.4. Calculating the EapFinished message . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	4.1. InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10		4.1. EapFinished vs. Finished . . . . . . . . . . . . . . . . . 11
	4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 10		4.2. Identity Protection . . . . . . . . . . . . . . . . . . . 11
	4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 11		4.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 12
	5. Performance Considerations . . . . . . . . . . . . . . . . . . 12		5. Performance Considerations . . . . . . . . . . . . . . . . . . 13
	6. Operational Considerations . . . . . . . . . . . . . . . . . . 13		6. Operational Considerations . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	9. Changes from Previous Versions . . . . . . . . . . . . . . . . 16		9. Changes from Previous Versions . . . . . . . . . . . . . . . . 17
	9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 16		9.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 17
	9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 16		9.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 17
	9.3. Changes from the protocol model draft . . . . . . . . . . 16		9.3. Changes from the protocol model draft . . . . . . . . . . 17
	10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		10.2. Informative References . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	This document describes a new extension to [TLS]. This extension		This document describes a new extension to [TLS]. This extension
	allows a TLS client to authenticate using [EAP] instead of performing		allows a TLS client to authenticate using [EAP] instead of performing
	the authentication at the application level. 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).
	skipping to change at page 5, line 29 ¶		skipping to change at page 6, line 29 ¶
	| | Infrastructure | | |		| | Infrastructure | | |
	| +--------------------+ | | +--------+		| +--------------------+ | | +--------+
	+-------------------------+ | | AAA |		+-------------------------+ | | AAA |
	| | Server |		| | Server |
	+----- |		+----- |
	+--------+		+--------+
	The above diagram shows the typical deployment. The client has		The above diagram shows the typical deployment. The client has
	software that either includes a UI for some EAP methods, or else is		software that either includes a UI for some EAP methods, or else is
	able to invoke some operating system EAP infrastructure that takes		able to invoke some operating system EAP infrastructure that takes
	care of the user interaction. The server is configured with the		care of the user interaction. Although the technical mechanisms have
	address and protocol of the AAA server. Typically the AAA server		been standardized for a AAA client to dynamically discover a AAA
	communicates using the RADIUS protocol with EAP ([RADIUS] and		server often the address of the AAA server is statically configured.
	[RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).		Typically the AAA server communicates using the RADIUS protocol with
			EAP ([RADIUS] and [RAD-EAP]), or the Diameter protocol ([Diameter]
			and [Dia-EAP]).
	As stated in the introduction, we expect TEE to be used in both		As stated in the introduction, we expect TEE to be used in both
	browsers and applications. Further uses may be authentication and		browsers and applications. Further uses may be authentication and
	key generation for other protocols, and tunneling clients, which so		key generation for other protocols, and tunneling clients, which so
	far have not been standardized.		far have not been standardized.
	3. Protocol Overview		3. Protocol Overview
	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,
	skipping to change at page 6, line 29 ¶		skipping to change at page 7, line 29 ¶
	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
	certain classes of phishing attacks.		certain classes of phishing attacks.
	The TEE extension defines the following:		The TEE extension defines the following:
	o A new extension type called tee_supported, used to indicate that		o A new extension type called tee_supported, used to indicate that
	the communicating application (either client or server) supports		the communicating application (either client or server) supports
	this extension.		this extension.
	o A new message type for the handshake protocol, called InterimAuth,
	which is used to sign previous messages.
	o A new message type for the handshake protocol, called EapMsg,		o A new message type for the handshake protocol, called EapMsg,
	which is used to carry a single EAP message.		which is used to carry a single EAP message.
			o A new message type for the handshake protocol, called EapFinished,
			which is used to sign previous messages.
	The diagram below outlines the protocol structure. For illustration		The diagram below outlines the protocol structure. For illustration
	purposes only, we use the GPSK EAP method [RFC5433].		purposes only, we use EAP Generalized Pre-Shared Key (EAP-GPSK)
			method [RFC5433]. This method is a lightweight shared-key
			authentication protocol supporting mutual authentication and key
			derivation.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello(*) -------->		ClientHello(*) -------->
	ServerHello(*)		ServerHello(*)
	(Certificate)		(Certificate)
	ServerKeyExchange		ServerKeyExchange
	EapMsg(Identity-Request)		EapMsg(Identity-Request)
	<-------- ServerHelloDone		<-------- ServerHelloDone
	ClientKeyExchange		ClientKeyExchange
	(CertificateVerify)		(CertificateVerify)
	ChangeCipherSpec		ChangeCipherSpec
	InterimAuth		Finished
	EapMsg(Identity-Reply) -------->		EapMsg(Identity-Reply) -------->
	ChangeCipherSpec		ChangeCipherSpec
	InterimAuth		Finished
	EapMsg(GPSK-Request)		EapMsg(GPSK-Request)
	<--------		<--------
	EapMsg(GPSK-Reply) -------->		EapMsg(GPSK-Reply) -------->
	EapMsg(GPSK-Request)		EapMsg(GPSK-Request)
	<--------		<--------
	EapMsg(GPSK-Reply) -------->		EapMsg(GPSK-Reply) -------->
	EapMsg(Success)		EapMsg(Success)
	<-------- Finished		<-------- EaoFinished
	Finished -------->		EapFinished -------->
	(*) The ClientHello and ServerHello include the tee_supported		(*) The ClientHello and ServerHello include the tee_supported
	extension to indicate support for TEE		extension to indicate support for TEE
	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 EapFinished Handshake Message
	The InterimAuth message is identical in syntax to the Finished		The EapFinished 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"		When TEE is used, application data cannot follow the "Finished"
	message indicates that application data may now be sent. The		message. Instead, it may only begin after the EapFinished message
	"InterimAuth" message does not indicate this. Instead, further
	handshake messages are needed.
	The HandshakeType value for the InterimAuth handshake message is TBA		The HandshakeType value for the EapFinished handshake message is TBA
	by IANA.		by IANA.
	3.3. The EapMsg Handshake Message		3.3. The EapMsg Handshake Message
	The EapMsg handshake message carries exactly one EAP message as		The EapMsg handshake message carries exactly one EAP message as
	defined in [EAP].		defined in [EAP].
	The HandshakeType value for the EapMsg handshake message is TBA by		The HandshakeType value for the EapMsg handshake message is TBA by
	IANA.		IANA.
	skipping to change at page 8, line 41 ¶		skipping to change at page 9, line 39 ¶
	not inspect the eap_payload within the EapMsg to detect success or		not inspect the eap_payload within the EapMsg to detect success or
	failure.		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 the		eap_payload is defined in section 4 of RFC 3748. It includes the
	Code, Identifier, Length and Data fields of the EAP packet.		Code, Identifier, Length and Data fields of the EAP packet.
	3.4. Calculating the Finished message		3.4. Calculating the EapFinished message
	If the EAP method is key-generating (see [RFC5247]), the Finished		If the EAP method is key-generating (see [RFC5247]), the Finished
	message is calculated as follows:		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) +
	skipping to change at page 9, line 6 ¶		skipping to change at page 10, line 4 ¶
	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 does not include all the data in the
	the data in the handshake. Instead it signs all the data that has		handshake. Instead it includes only the data that has not been
	not been signed by the previous InterimAuth message. The		signed by the previous Finished message. The handshake_messages
	handshake_messages field includes all of the octets beginning with		field includes all of the octets beginning with and including the
	and including the InterimAuth message, up to but not including this		Finished message, up to but not including this EapFinished message.
	Finished message. This is the concatenation of all the Handshake		This is the concatenation of all the Handshake structures exchanged
	structures exchanged thus far, and not yet signed, as defined in		thus far, and not yet signed, as defined in section 7.4 of [TLS]and
	section 7.4 of [TLS]and in this document.		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.
	4. Security Considerations		4. Security Considerations
	4.1. InterimAuth vs. Finished		4.1. EapFinished vs. Finished
	In regular TLS, the Finished message provides two functions: it signs		In regular TLS, the Finished message provides two functions: it signs
	all preceding messages, and it signals that application data can now		all preceding messages, and it signals that application data can now
	be sent. In TEE, it only signs those messages that have not yet been		be sent. In TEE, it only signs, and the signal is given by
	signed.		EapFinished.
	Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate		Many EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM, generate
	keys in addition to authenticating clients. Such methods are said to		keys in addition to authenticating clients. Such methods are
	be resistant to man-in-the-middle (MITM) attacks as discussed in		resistant to man-in-the-middle (MITM) attacks, as discussed in [MITM]
	[MITM]. Such methods are called key-generating methods.		and are called key-generating methods.
	To realize the benefit of such methods, we need to verify the key		To realize the benefit of such methods, we need to verify the key
	that was generated within the EAP method. This is referred to as the		that was generated within the EAP method. This is referred to as the
	MSK in EAP. In TEE, the InterimAuth message signs all previous		MSK in EAP. In TEE, the EapFinished message signs the messages that
	messages with the master_secret, just like the Finished message in		have not yet been signed by the Finished message using the MSK if
	regular TLS. The Finished message signs the rest of the messages		such exists. If not, then the messages are signed with the
	using the MSK if such exists. If not, then the messages are signed		master_secret as in regular TLS.
	with the master_secret as in regular TLS.
	The need for signing twice arises from the fact that we need to use		The need for signing twice arises from the fact that we need to use
	both the master_secret and the MSK. It was possible to use just one		both the master_secret and the MSK. It was possible to use just one
	Finished record and blend the MSK into the master_secret. However,		Finished record and blend the MSK into the master_secret. However,
	this would needlessly complicate the protocol and make security		this would needlessly complicate the protocol and make security
	analysis more difficult. Instead, we have decided to follow the		analysis more difficult. Instead, we have decided to follow the
	example of IKEv2, where two AUTH payloads are exchanged.		example of IKEv2, where two AUTH payloads are exchanged.
	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
	skipping to change at page 11, line 17 ¶		skipping to change at page 12, line 17 ¶
	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
	obviously done using the EAP method. The server authentication can		obviously done using the EAP method. The server authentication can
	be done in either of two ways:		be done in either of two ways:
	1. The client can verify the server certificate. This may work well		1. The client can verify the server certificate. This may work well
	depending on the scenario, but implies that the client or its		depending on the scenario, but implies that the client or its
	user can recognize the right DN or alternate name, and		user can recognize the right DN or alternate name, and
	distinguish it from plausible alternatives. The introduction to		distinguish it from plausible alternatives. The introduction to
	[I.D.Webauth-phishing] shows that at least in HTTPS, this is not		[I.D.Webauth-phishing] shows that at least in HTTPS, this is not
	always the case.		always the case.
	2. The client can use a mutually authenticated (MA) EAP method such		2. The client can use a mutually authenticated (MA) EAP method, such
	as GPSK. In this case, server certificate verification does not		as EAP-GPSK. The client would be authenticated to the AAA server
	matter, and the TLS handshake may as well be anonymous. Note		and vice versa. Additionally authenticating the application
	that in this case, the client identity is sent to the server		server to the client is not necessary and the TLS handshake may
	before server authentication.		as well be anonymous. Note that the authenticated client
			identity may be sent from the AAA server to the application
			server (acting as a AAA client) if the authenticated identity
			indeed matters for the purpose of the service fulfillment and
			with the user's permission.
	To summarize:		To summarize:
	o Clients MUST NOT propose anonymous ciphersuites, unless they		o Clients MUST NOT propose anonymous ciphersuites, unless they
	support MA EAP methods.		support MA EAP methods.
	o Clients MUST NOT accept non-MA methods if the ciphersuite is		o Clients MUST NOT accept non-MA methods if the ciphersuite is
	anonymous.		anonymous.
	o Clients MUST NOT accept non-MA methods if they are not able to		o Clients MUST NOT accept non-MA methods if they are not able to
	verify the server credentials. Note that this document does not		verify the server credentials. Note that this document does not
	define what verification involves. If the server DN is known and		define what verification involves. If the server DN is known and
	stored on the client, verifying certificate signature and checking		stored on the client, verifying certificate signature and checking
	skipping to change at page 14, line 11 ¶		skipping to change at page 15, line 11 ¶
	requiring the user to type in credentials after the connection has		requiring the user to type in credentials after the connection has
	already started. TCP sessions may time out, because of security		already started. TCP sessions may time out, because of security
	considerations, and this may lead to session setup failure.		considerations, and this may lead to session setup failure.
	7. IANA Considerations		7. IANA Considerations
	IANA is asked to assign an extension type value from the		IANA is asked to assign an extension type value from the
	"ExtensionType Values" registry for the tee_supported extension.		"ExtensionType Values" registry for the tee_supported extension.
	IANA is asked to assign two handshake message types from the "TLS		IANA is asked to assign two handshake message types from the "TLS
	HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".		HandshakeType Registry", one for "EapMsg" and one for "EapFinished".
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank Josh Howlett for his comments.		The authors would like to thank Josh Howlett for his comments.
	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.
	skipping to change at page 17, line 5 ¶		skipping to change at page 18, line 5 ¶
	9.3. Changes from the protocol model draft		9.3. Changes from the protocol model draft
	o Added diagram for EapMsg		o Added diagram for EapMsg
	o Added discussion of EAP applicability		o Added discussion of EAP applicability
	o Added discussion of mutually-authenticated EAP methods vs other		o Added discussion of mutually-authenticated EAP methods vs other
	methods in the security considerations.		methods in the security considerations.
	o Added operational considerations.		o Added operational considerations.
	o Other minor nits.		o Other minor nits.
	10. Open Issues		10. References
	Some have suggested that since the protocol is identical to regular
	TLS up to the InterimAuth message, we should call that the Finished
	message, and call the last message in the extended handshake
	something like "EapFinished". This has the advantage that the
	construction of Finished is already well defined and will not change.
	However, the Finished message has a specific meaning as indicated by
	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
	called InterimAuth. We'd like the opinions of reviewrs about this
	issue.
	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
	followed the example of IKEv2. The reason is that TLS already has
	perfectly good ways of exchanging keys, and we do not need this
	capability from EAP methods. Also, using the MSK in keys would
	require an additional ChangeCipherSpec and would complicate the
	protocol. We'd like the opinions of reviewrs about this issue.
	Another response we got was that we should have a MUST requirement
	that only mutually authenticated and key-generating methods be used
	in TEE. This would simplify the security considerations section.
	While we agree that this is a good idea, most EAP methods in common
	use are not compliant. Additionally, such requirements assume that
	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
	may not be required. If we consider the server authenticated by its
	certificate, it may be acceptable to use a non-MA method.
	It has been suggested that identity protection is not important
	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
	about this, and would like to solicit the reviewers opinion. Note
	that if this is done, the client sends the user name before ever
	receiving any indication that the server actually supports TEE. This
	might be acceptable in an email client, where the server is
	preconfigured, but it may be unacceptable in other uses, such as web
	browsers.
	11. References
	11.1. Normative References		10.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.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[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.
	11.2. Informative References		10.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.
End of changes. 30 change blocks.
	125 lines changed or deleted		103 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/