< draft-ietf-nfsv4-channel-bindings-02.txt		draft-ietf-nfsv4-channel-bindings-03.txt >
	NETWORK WORKING GROUP N. Williams		NETWORK WORKING GROUP N. Williams
	Internet-Draft Sun		Internet-Draft Sun
	Expires: January 13, 2005 July 15, 2004		Expires: August 23, 2005 February 22, 2005
	On the Use of Channel Bindings to Secure Channels		On the Use of Channel Bindings to Secure Channels
	draft-ietf-nfsv4-channel-bindings-02.txt		draft-ietf-nfsv4-channel-bindings-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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 32 ¶		skipping to change at page 1, line 33 ¶
	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 January 13, 2005.		This Internet-Draft will expire on August 23, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	This document defines and formalizes the concept of channel bindings		This document defines and formalizes the concept of channel bindings
	to secure layers and defines the channel bindings for several types		to secure layers and defines the channel bindings for several types
	of secure channels.		of secure channels.
	The concept of channel bindings allows applications to prove that the		The concept of channel bindings allows applications to prove that the
	end-points of two secure channels at different network layers are the		end-points of two secure channels at different network layers are the
	same by binding authentication at one channel to the session		same by binding authentication at one channel to the session
	skipping to change at page 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	may significantly improve performance for some applications.		may significantly improve performance for some applications.
	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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Authentication protocols and channel bindings . . . . . . . . 7		4. Authentication protocols and channel bindings . . . . . . . . 7
	4.1 The GSS-API and channel bindings . . . . . . . . . . . . . 7		4.1 The GSS-API and channel bindings . . . . . . . . . . . . . 7
	4.2 SASL and channel bindings . . . . . . . . . . . . . . . . 7		4.2 SASL and channel bindings . . . . . . . . . . . . . . . . 7
	5. Channel bindings for various secure layers . . . . . . . . . . 8		5. Channel bindings for various secure layers . . . . . . . . . . 9
	5.1 Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 8		5.1 Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 9
	5.2 Bindings to TLS channels . . . . . . . . . . . . . . . . . 8		5.2 Bindings to TLS channels . . . . . . . . . . . . . . . . . 9
	5.3 Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 8		5.3 Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 9
	5.3.1 Interfaces for creating IPsec channels . . . . . . . . 9		5.3.1 Interfaces for creating IPsec channels . . . . . . . . 10
	5.4 Bindings to other types of channels . . . . . . . . . . . 9		5.4 Bindings to other types of channels . . . . . . . . . . . 10
	6. Benefits of channel bindings to secure channels . . . . . . . 10		6. Benefits of channel bindings to secure channels . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 12		8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
	A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . 15
	1. Conventions used in this document		1. 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. Introduction		2. Introduction
	Over the years several attempts have been made to delegate session		Over the years several attempts have been made to delegate session
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	being proposed separately. [NOTE: Indirect reference to CCM...]		being proposed separately. [NOTE: Indirect reference to CCM...]
	However, it does not, at this time, seem feasible to use SPNEGO with		However, it does not, at this time, seem feasible to use SPNEGO with
	such pseudo-mechanisms for negotiating the use of channel bindings.		such pseudo-mechanisms for negotiating the use of channel bindings.
	4.2 SASL and channel bindings		4.2 SASL and channel bindings
	SASL does not provide for the use of channel bindings during		SASL does not provide for the use of channel bindings during
	initialization of SASL contexts.		initialization of SASL contexts.
	SASL applications MAY define their own exchange of integrity-		SASL applications MAY define their own exchange of
	protected channel bindings using established SASL integrity layers.		integrity-protected channel bindings using established SASL integrity
			layers.
	Alternatively, SASL applications MAY use the GSS-* SASL mechanisms		Alternatively, SASL applications MAY use the GSS-* SASL mechanisms
	(which correspond to GSS-API mechanisms) to ensure the use of channel		(which correspond to GSS-API mechanisms) to ensure the use of channel
	bindings through the GSS-API's facilities; this approach may require		bindings through the GSS-API's facilities; this approach may require
	more study and specification elsewhere.		more study and specification elsewhere.
	5. Channel bindings for various secure layers		5. Channel bindings for various secure layers
	Not every secure session protocol or interface provides for secure		Not every secure session protocol or interface provides for secure
	channels, and not every secure session protocol provides data		channels, and not every secure session protocol provides data
	skipping to change at page 8, line 37 ¶		skipping to change at page 9, line 37 ¶
	Note that the TLS "session ID," in spite of being named similarly to		Note that the TLS "session ID," in spite of being named similarly to
	the SSHv2 session ID, is not suitable for use as channel bindings		the SSHv2 session ID, is not suitable for use as channel bindings
	because it is assigned by the server, so a MITM could assign the same		because it is assigned by the server, so a MITM could assign the same
	session ID on the client side as it gets from the server.		session ID on the client side as it gets from the server.
	5.3 Bindings to IPsec		5.3 Bindings to IPsec
	IPsec does not provide for secure channels by itself, as it protects		IPsec does not provide for secure channels by itself, as it protects
	individual packets. Further, the IPsec SAs used to protect the		individual packets. Further, the IPsec SAs used to protect the
	packets for some channel (e.g., a TCP connection) need not be related		packets for some channel (e.g., a TCP connection) over its lifetime
	in any way that allows for construction of channel bindings.		need not be related in any way that allows for construction of
			channel bindings.
	There is a set of IPsec parameters that may be kept constant for all		There is a set of IPsec parameters that may be kept constant for all
	IP packets for a given channel (e.g., a TCP connection):		IP packets for a given channel (e.g., a TCP connection):
	o the peers' authenticated IPsec IDs		o the peers' authenticated IPsec IDs
	o the SA types (e.g., transport mode ESP)		o the SA types (e.g., transport mode ESP)
	o the privacy and integrity protection algorithms used		o the privacy and integrity protection algorithms used
	[QUESTION: Should IPsec traffic selectors, that is, the protocol
	(TCP, UDP, SCTP) and port numbers used for the channel be
	included?]
	Provided interfaces for binding a channel to these IPsec parameters		Provided interfaces for binding a channel to these IPsec parameters
	it is possible to construct a channel secured by IPsec.		it is possible to construct a channel secured by IPsec.
	The channel bindings for such a channel, then, are the values of		The channel bindings for such a channel, then, are the values of
	those IPsec parameters to which the channel is bound.		those IPsec parameters to which the channel is bound.
	Requirements for such interfaces to IPsec are specified in		Requirements for such interfaces to IPsec are specified in
	[IPSP-APIREQ].		[IPSP-APIREQ].
	5.3.1 Interfaces for creating IPsec channels		5.3.1 Interfaces for creating IPsec channels
	skipping to change at page 9, line 23 ¶		skipping to change at page 10, line 20 ¶
	In order to build an IPsec channel some additional application		In order to build an IPsec channel some additional application
	programming interfaces are needed to:		programming interfaces are needed to:
	o indicate that an as yet unconnected channel is to be bound to		o indicate that an as yet unconnected channel is to be bound to
	IPsec IDs and		IPsec IDs and
	o explicitly specify one, the other or both of those IDs		o explicitly specify one, the other or both of those IDs
	o implicitly specify one, the other or both of those IDs (e.g., the		o implicitly specify one, the other or both of those IDs (e.g., the
	ID corresponding to the current application program instance)		ID corresponding to the current application program instance)
	o indirectly specify one, the other or both of those IDs (e.g.,		o indirectly specify one, the other or both of those IDs (e.g.,
	through IP addresses or hostnames)		through IP addresses or hostnames)
			o explicitly specify ESP and/or AH and associated algorithms
	and/or		and/or
	o discover the IPsec IDs to which a channel is bound		o discover the IPsec parameters to which a channel is bound
	For connection-less datagram transports the IDs to be used need to be		For connection-less datagram transports the IDs to be used need to be
	specified/discovered on a per-datagram basis.		specified/discovered on a per-datagram basis.
	See [IPSP-APIREQ].		See [IPSP-APIREQ].
	5.4 Bindings to other types of channels		5.4 Bindings to other types of channels
	Channel bindings for other secure session protocols are not specified		Channel bindings for other secure session protocols are not specified
	here.		here.
	skipping to change at page 14, line 41 ¶		skipping to change at page 15, line 41 ¶
	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 AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 12 change blocks.
	28 lines changed or deleted		28 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/