< draft-altman-tls-channel-bindings-09.txt		draft-altman-tls-channel-bindings-10.txt >
	NETWORK WORKING GROUP J. Altman		NETWORK WORKING GROUP J. Altman
	Internet-Draft Secure Endpoints		Internet-Draft Secure Endpoints
	Intended status: Standards Track N. Williams		Intended status: Standards Track N. Williams
	Expires: September 24, 2010 Oracle		Expires: October 1, 2010 Oracle
	L. Zhu		L. Zhu
	Microsoft Corporation		Microsoft Corporation
	March 23, 2010		March 30, 2010
	Channel Bindings for TLS		Channel Bindings for TLS
	draft-altman-tls-channel-bindings-09.txt		draft-altman-tls-channel-bindings-10.txt
	Abstract		Abstract
	This document defines three channel binding types for Transport Layer		This document defines three channel binding types for Transport Layer
	Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-		Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-
	telnet, in accordance with RFC 5056 (On Channel Binding).		telnet, in accordance with RFC 5056 (On Channel Binding).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 September 24, 2010.		This Internet-Draft will expire on October 1, 2010.
	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 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Conventions used in this document . . . . . . . . . . . . . 3		1. Conventions used in this document . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. The 'tls-unique' Channel Binding Type . . . . . . . . . . . 5		3. The 'tls-unique' Channel Binding Type . . . . . . . . . . . 5
	3.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. The 'tls-server-end-point' Channel Binding Type . . . . . . 7		4. The 'tls-server-end-point' Channel Binding Type . . . . . . 7
	4.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. The 'tls-unique-for-telnet' Channel Binding Type . . . . . . 9		5. The 'tls-unique-for-telnet' Channel Binding Type . . . . . . 9
	5.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Description . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Applicability of TLS Channel Binding Types . . . . . . . . . 11		6. Applicability of TLS Channel Binding Types . . . . . . . . . 11
	7. Required Application Programming Interfaces . . . . . . . . 14		7. Required Application Programming Interfaces . . . . . . . . 14
	8. Description of backwards-incompatible changes made		8. Description of backwards-incompatible changes made
	herein to 'tls-unique' . . . . . . . . . . . . . . . . . . . 15		herein to 'tls-unique' . . . . . . . . . . . . . . . . . . . 15
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 26 ¶
	struct) in the most recent TLS handshake of the TLS connection being		struct) in the most recent TLS handshake of the TLS connection being
	bound to (note: TLS connection, not session, so that the channel		bound to (note: TLS connection, not session, so that the channel
	binding is specific to each connection regardless of whether session		binding is specific to each connection regardless of whether session
	resumption is used). If TLS re-negotiation takes place before the		resumption is used). If TLS re-negotiation takes place before the
	channel binding operation, then the first TLS Finished message sent		channel binding operation, then the first TLS Finished message sent
	of the latest/inner-most TLS connection is used. Note that for full		of the latest/inner-most TLS connection is used. Note that for full
	TLS handshakes the first Finished message is sent by the client,		TLS handshakes the first Finished message is sent by the client,
	while for abbreviated TLS handshakes (session resumption) the first		while for abbreviated TLS handshakes (session resumption) the first
	Finished message is sent by the server.		Finished message is sent by the server.
	Interoperability note: this definition of tls-unique means that the
	channel's bindings data may change over time, which in turn creates a
	synchronization problem should the channel's bindings data change
	between the time that the client initiates authentication with
	channel binding and the time that the server begins to process the
	client's first authentication message. If that happens the
	authentication will fail spuriously. To avoid this problem client
	applications SHOULD ensure that TLS re-negotiation does not occur
	between the start and completion of authentication.
	WARNING: The definition, security and interoperability considerations		WARNING: The definition, security and interoperability considerations
	of this channel binding type have changed since the original		of this channel binding type have changed since the original
	registration. Implementors should read the document that last		registration. Implementors should read the document that last
	updated this registration for more information.		updated this registration for more information.
			Interoperability note:
			This definition of tls-unique means that the channel's bindings
			data may change over time, which in turn creates a synchronization
			problem should the channel's bindings data change between the time
			that the client initiates authentication with channel binding and
			the time that the server begins to process the client's first
			authentication message. If that happens the authentication will
			fail spuriously.
			This synchronization problem can be avoided by clients and servers
			as follows, based on the fact that while servers may request TLS
			re-negotiation, only clients may initiate it. Server applications
			MUST NOT request TLS re-negotiation during phases of the
			application protocol during which application layer authentication
			occurs. Client applications SHOULD NOT initiate TLS re-
			negotiation between the start and completion of authentication.
			The rationale for making the server behavior a requirement while
			the client behavior is only a recommendation is that there
			typically exist TLS APIs for requesting re-negotiation on the
			server side of a TLS connection, while many client TLS stacks do
			not provide fine-grained control over when TLS re-negotiation
			occurs.
			Application protocols should be designed in such a way that a
			server would never need to request TLS re-negotiation immediately
			before or during application-layer authentication.
	3.2. Registration		3.2. Registration
	o Channel binding unique prefix: tls-unique		o Channel binding unique prefix: tls-unique
	o Channel binding type: unique		o Channel binding type: unique
	o Channel type: TLS [RFC5246]		o Channel type: TLS [RFC5246]
	o Published specification: <this document>		o Published specification: <this document>
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 10 ¶
	o TLS_ECDHE_PSK_WITH_*		o TLS_ECDHE_PSK_WITH_*
	o TLS_ECDH_anon_WITH_*		o TLS_ECDH_anon_WITH_*
	o TLS_KRB5_WITH_*		o TLS_KRB5_WITH_*
	o TLS_PSK_WITH_*		o TLS_PSK_WITH_*
	o TLS_SRP_SHA_WITH_*		o TLS_SRP_SHA_WITH_*
	Nor is this channel binding type available for use with OpenPGP		Nor is 'tls-server-end-point' applicable for use with OpenPGP server
	server certificates [RFC5081] [RFC4880] (since these don't use the		certificates [RFC5081] [RFC4880] (since these don't use the
	Certificate handshake message).		Certificate handshake message).
	Therefore 'tls-unique' is generally better than 'tls-server-end-		Therefore 'tls-unique' is generally better than 'tls-server-end-
	point'. However, 'tls-server-end-point' may be used with existing		point'. However, 'tls-server-end-point' may be used with existing
	TLS server-side proxies ("concentrators") without modification to the		TLS server-side proxies ("concentrators") without modification to the
	proxies, whereas 'tls-unique' may require firmware or software		proxies, whereas 'tls-unique' may require firmware or software
	updates to server-side proxies. Therefore there may be cases where		updates to server-side proxies. Therefore there may be cases where
	'tls-server-end-point' may interoperate but where 'tls-unique' may		'tls-server-end-point' may interoperate but where 'tls-unique' may
	not.		not.
	Also, authentications mechanisms may arise which depend on channel		Also, authentication mechanisms may arise which depend on channel
	bindings to contribute entropy, in which case unique channel bindings		bindings to contribute entropy, in which case unique channel bindings
	would have to always be used in preference to end-point channel		would have to always be used in preference to end-point channel
	bindings. At this time there are no such mechanisms, though one such		bindings. At this time there are no such mechanisms, though one such
	SASL mechanism has been proposed. Whether such mechanisms should be		SASL mechanism has been proposed. Whether such mechanisms should be
	allowed is out of scope for this document.		allowed is out of scope for this document.
	In other words, for many applications there may be two potentially		In other words, for many applications there may be two potentially
	applicable TLS channel binding types. Channel binding is all or		applicable TLS channel binding types. Channel binding is all or
	nothing for the GSS-API [RFC2743], and likely other frameworks.		nothing for the GSS-API [RFC2743], and likely other frameworks.
	Therefore agreement on the use of channel binding, and a particular		Therefore agreement on the use of channel binding, and a particular
	skipping to change at page 16, line 5 ¶		skipping to change at page 15, line 22 ¶
	bindings data for a given connection and channel binding type.		bindings data for a given connection and channel binding type.
	Alternatively the implementor may provide interfaces by which to		Alternatively the implementor may provide interfaces by which to
	obtain the initial client Finished message, the initial server		obtain the initial client Finished message, the initial server
	Finished message and/or the server certificate (in a form that		Finished message and/or the server certificate (in a form that
	matches the description of the 'tls-server-end-point' channel binding		matches the description of the 'tls-server-end-point' channel binding
	type). In the latter case the application has to have knowledge of		type). In the latter case the application has to have knowledge of
	the channel binding type descriptions from this document. This		the channel binding type descriptions from this document. This
	document takes no position on which form these application		document takes no position on which form these application
	programming interfaces must take.		programming interfaces must take.
			TLS implementations supporting TLS re-negotiation SHOULD provide APIs
			that allow for application control over when re-negotiation can take
			place. For example, a TLS client implementation may provide a
			"callback" interface to indicate that the server requested re-
			negotiation, but may not start re-negotiation until the application
			calls a function to indicate that now is a good time to re-negotiate.
	8. Description of backwards-incompatible changes made herein to 'tls-		8. Description of backwards-incompatible changes made herein to 'tls-
	unique'		unique'
	The original description of 'tls-unique' read as follows:		The original description of 'tls-unique' read as follows:
	|OLD| Description: The client's TLS Finished message (note: the		|OLD| Description: The client's TLS Finished message (note: the
	|OLD| Finished struct) from the first handshake of the connection		|OLD| Finished struct) from the first handshake of the connection
	|OLD| (note: connection, not session, so that the channel binding		|OLD| (note: connection, not session, so that the channel binding
	|OLD| is specific to each connection regardless of whether session		|OLD| is specific to each connection regardless of whether session
	|OLD| resumption is used).		|OLD| resumption is used).
	skipping to change at page 16, line 45 ¶		skipping to change at page 16, line 45 ¶
	original semantics, but we know of no deployed application using		original semantics, but we know of no deployed application using
	the same. Implementations of the original and new 'tls-unique'		the same. Implementations of the original and new 'tls-unique'
	channel binding type will only interoperate when: a) full TLS		channel binding type will only interoperate when: a) full TLS
	handshakes are used, b) TLS re-negotiation is not used.		handshakes are used, b) TLS re-negotiation is not used.
	o Security considerations -- see Section 10.		o Security considerations -- see Section 10.
	o Interoperability considerations. As described in Section 3 the		o Interoperability considerations. As described in Section 3 the
	new definition of the 'tls-unique' channel binding type has an		new definition of the 'tls-unique' channel binding type has an
	interoperability problem that may result in spurious		interoperability problem that may result in spurious
	authentication failures unless the client implements the technique		authentication failures unless the application implements one or
	described in that section.		both of the the techniques described in that section.
	9. IANA Considerations		9. IANA Considerations
	The IANA is hereby directed to update three existing channel binding		The IANA is hereby directed to update three existing channel binding
	type registrations. See the rest of this document.		type registrations. See the rest of this document.
	10. Security Considerations		10. Security Considerations
	The Security Considerations sections of [RFC5056], [RFC5246] and		The Security Considerations sections of [RFC5056], [RFC5246] and
	[RFC5746] apply to this document.		[RFC5746] apply to this document.
End of changes. 11 change blocks.
	20 lines changed or deleted		46 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/