draft-josefsson-sasl-external-channel-00.txt		draft-josefsson-sasl-external-channel-01.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD		Internet-Draft SJD AB
	Intended status: Standards Track August 5, 2008		Intended status: Standards Track April 14, 2009
	Expires: February 6, 2009		Expires: October 16, 2009
	SASL Mechanism for External Authentication using Channel Bindings:		SASL Mechanism for External Authentication using a Named Channel:
	EXTERNAL-CHANNEL		EXTERNAL-CHANNEL
	draft-josefsson-sasl-external-channel-00		draft-josefsson-sasl-external-channel-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79. This document may contain material
	have been or will be disclosed, and any of which he or she becomes		from IETF Documents or IETF Contributions published or made publicly
	aware will be disclosed, in accordance with Section 6 of BCP 79.		available before November 10, 2008. The person(s) controlling the
			copyright in some of this material may not have granted the IETF
			Trust the right to allow modifications of such material outside the
			IETF Standards Process. Without obtaining an adequate license from
			the person(s) controlling the copyright in such materials, this
			document may not be modified outside the IETF Standards Process, and
			derivative works of it may not be created outside the IETF Standards
			Process, except to format it for publication as an RFC or to
			translate it into languages other than English.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 February 6, 2009.		This Internet-Draft will expire on October 16, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	This document describes a way to perform end-user authentication in		This document describes a way to perform end-user authentication in
	the Simple Authentication and Security Layer (SASL) framework which		the Simple Authentication and Security Layer (SASL) framework by re-
	re-use an external security layer (such as the Transport Layer		using an external security layer (such as the Transport Layer
	Security (TLS) protocol) that may have already completed end-user		Security (TLS) protocol) that may have already completed end-user
	authentication. In comparison with the existing EXTERNAL mechanism,		authentication. In comparison with the existing EXTERNAL mechanism,
	this mechanism offers a way to cryptographically bind the		this mechanism alleviates the a priori assumptions made by the design
	authentication to the security layer via a channel binding. The		of the EXTERNAL mechanism. This mechanism transfers an identifier of
	EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made		the external channel to be used explicitly.
	by the design of the EXTERNAL mechanism.
	See <http://josefsson.org/external-channel/> for more information.		See <http://josefsson.org/external-channel/> for more information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Technical Specification . . . . . . . . . . . . . . . . . . . 3		2. Technical Specification . . . . . . . . . . . . . . . . . . . . 4
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Making Authorization Decisions . . . . . . . . . . . . . . . . 6		4. Making Authorization Decisions . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The EXTERNAL mechanism, described in Appendix A of [RFC4422] allows a		The EXTERNAL mechanism, described in Appendix A of [RFC4422] allows a
	client to request the server to use credentials established by means		client to request the server to use credentials established by means
	external to the mechanism to authenticate the client. The external		external to the mechanism to authenticate the client. The external
	means may be, for instance, TLS [RFC4346] or IP Security [RFC4301]		means may be, for instance, TLS [RFC5246] or IP Security [RFC4301]
	services.		services.
	The EXTERNAL mechanism requires some a prior agreement between the		The EXTERNAL mechanism requires some a prior agreement between the
	client and the server regarding which external channel, and		client and the server regarding which external channel, and
	consequently which external credentials, should be used for		consequently which external credentials, should be used for
	authentication. In practice this has often meant that the EXTERNAL		authentication. In practice this has often meant that the EXTERNAL
	mechanism is only used when there is tight out of band interaction		mechanism is only used when there is tight out of band interaction
	between the server administration and client user. This has an		between the server administration and client user. This has impacted
	impact of the interoperability of the EXTERNAL mechanism.		the interoperability of the EXTERNAL mechanism.
	The EXTERNAL-CHANNEL mechanism, specified in this document, is		The EXTERNAL-CHANNEL mechanism, specified in this document, is
	similar to the EXTERNAL mechanism in that it relies on an external		similar to the EXTERNAL mechanism in that it relies on an external
	channel to perform the user authentication. However, EXTERNAL-		channel to perform the user authentication. However, EXTERNAL-
	CHANNEL provides a way for the client to provide an identifier of the		CHANNEL provides a way for the client to provide an identifier of the
	external channel that provides the user credentials. The intention		external channel that provides the user credentials. The intention
	is that the server need not rely on a priori arrangement to identify		is that the server need not rely on a priori arrangement to identify
	the secure channel that was used, but can automatically find the		the secure channel that was used, but can automatically find the
	intended channel and re-use its credentials for the SASL		intended channel and re-use its credentials for the SASL
	authentication.		authentication.
	In the EXTERNAL-CHANNEL mechanism the external channel is identified		In the EXTERNAL-CHANNEL mechanism, the external channel is identified
	using the "Channel binding unique prefix" string as defined in		using the "Channel binding unique prefix" string as defined in
	[RFC5056]. A channel bindings is transferred, so that the server can		[RFC5056].
	verify that the client is a peer of the same secure channel as the
	server.
	Binding authentication to a specific encrypted session can protect
	from certain attacks [MITM]. It can also help to improve performance
	by having peers agree to re-use a secure channel rather than to set
	up a new.
	2. Technical Specification		2. Technical Specification
	The name of this mechanism is "EXTERNAL-CHANNEL".		The name of this mechanism is "EXTERNAL-CHANNEL".
	The mechanism does not provide a security layer. It provides similar		The mechanism does not provide a security layer. It provides similar
	functionality by relying on an external channel.		functionality by relying on an external channel.
	The mechanism is capable of transferring a channel binding and an		The mechanism is capable of transferring a channel name and an
	authorization identity string. If the authorization identity string		authorization identity string. If the authorization identity string
	is empty, the client is requesting to act as the identity the server		is empty, the client is requesting to act as the identity the server
	has associated with the client's credentials. If the authorization		has associated with the client's credentials. If the authorization
	identity string is non-empty, the client is requesting to act as the		identity string is non-empty, the client is requesting to act as the
	identity represented by the string. The channel binding name cannot		identity represented by the string. The channel name cannot be
	be empty.		empty.
	The client is expected to send data first in the authentication		The client is expected to send data first in the authentication
	exchange. Where the client does not provide an initial response data		exchange. Where the client does not provide an initial response data
	in its request to initiate the authentication exchange, the server is		in its request to initiate the authentication exchange, the server is
	to respond to the request with an empty initial challenge and then		to respond to the request with an empty initial challenge and then
	the client is to provide its initial response.		the client is to provide its initial response.
	The client sends the initial response containing the channel binding		The client sends the initial response containing the channel name,
	name, a base64 [RFC4648] encoded channel bindings, and a UTF-8		and a UTF-8 [RFC3629] encoding of the requested authorization
	[RFC3629] encoding of the requested authorization identity string.		identity string.
	The authorization identity is non-empty when the client is requesting		The authorization identity is non-empty when the client is requesting
	to act as the identity represented by the (non-empty) string. The		to act as the identity represented by the (non-empty) string. The
	authorization identity is empty when the client is requesting to act		authorization identity is empty when the client is requesting to act
	as the identity the server associates with the external		as the identity the server associates with the external
	authentication credentials.		authentication credentials.
	The syntax of the initial response is specified as a value of the		The syntax of the initial response is specified as a value of the
	<extern-initial-resp> production detailed below using the Augmented		<extern-initial-resp> production detailed below using the Augmented
	Backus-Naur Form (ABNF) [RFC4234] notation.		Backus-Naur Form (ABNF) [RFC5234] notation.
	external-initial-resp = cb-name " " b64-cb-data " " authz-id-string		external-initial-resp = cb-name " " authz-id-string
	cb-name = 1*( US-ASCII / "." / "-")		cb-name = 1*( US-ASCII / "." / "-")
	;; Based on RFC 5056: "There is no naming convention for channel		;; Based on RFC 5056: "There is no naming convention for channel
	;; bindings: any string composed of US-ASCII alphanumeric		;; bindings: any string composed of US-ASCII alphanumeric
	;; characters, period ('.'), and dash ('-') will suffice."		;; characters, period ('.'), and dash ('-') will suffice."
	b64-cb-data = *( ALPHA / DIGIT / "+" / "/" / "=" )
	;; Base64 encoding of the channel bindings, the format
	;; of the decoded data depends on the cb-name.
	authz-id-string = *( UTF8-char-no-nul )		authz-id-string = *( UTF8-char-no-nul )
	UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4		UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
	;; where the UTF8-2, UTF8-3, and UTF8-4 productions are		;; where the UTF8-2, UTF8-3, and UTF8-4 productions are
	;; as defined in RFC 3629.		;; as defined in RFC 3629.
	UTF8-1-no-nul = %x01-7F		UTF8-1-no-nul = %x01-7F
	There are no additional challenges and responses.		There are no additional challenges and responses.
	Hence, the server is to return the outcome of the authentication		Hence, the server is to return the outcome of the authentication
	exchange.		exchange.
	The exchange fails if		The exchange fails if
	- the cb-name denote an (to the server implementation) unknown or		- the cb-name denote an (to the server implementation) unknown or
	end-point channel binding type,		end-point channel binding type,
	- the client has not established its credentials via the indicated		- the client has not established its credentials via the indicated
	external channel,		external channel,
	- the channel bindings data does not match,
	- the client's credentials are inadequate,		- the client's credentials are inadequate,
	- the client provided an empty authorization identity string and the		- the client provided an empty authorization identity string and the
	server is unwilling or unable to associate an authorization identity		server is unwilling or unable to associate an authorization identity
	with the client's credentials,		with the client's credentials,
	- the client provided a non-empty authorization identity string that		- the client provided a non-empty authorization identity string that
	is invalid per the syntax requirements of the applicable application		is invalid per the syntax requirements of the applicable application
	protocol specification,		protocol specification,
	skipping to change at page 5, line 44		skipping to change at page 6, line 30
	3. Examples		3. Examples
	This section provides examples of EXTERNAL-CHANNEL authentication		This section provides examples of EXTERNAL-CHANNEL authentication
	exchanges. The examples are intended to help the readers understand		exchanges. The examples are intended to help the readers understand
	the above text. The examples are not definitive. The Application		the above text. The examples are not definitive. The Application
	Configuration Access Protocol (ACAP) [RFC2244] is used in the		Configuration Access Protocol (ACAP) [RFC2244] is used in the
	examples because ACAP sends the SASL tokens without additional		examples because ACAP sends the SASL tokens without additional
	encoding.		encoding.
	The first example shows use of EXTERNAL-CHANNEL with an empty		The first example shows use of EXTERNAL-CHANNEL with an empty
	authorization identity bound to an external "tls-unique" channel. In		authorization identity and an external "tls-unique" channel. In this
	this example, the initial response is not sent in the client's		example, the initial response is not sent in the client's request to
	request to initiate the authentication exchange.		initiate the authentication exchange.
	S: * ACAP (SASL "DIGEST-MD5")		S: * ACAP (SASL "DIGEST-MD5")
	C: a001 STARTTLS		C: a001 STARTTLS
	S: a001 OK "Begin TLS negotiation now"		S: a001 OK "Begin TLS negotiation now"
	<TLS negotiation, further commands are under TLS layer>		<TLS negotiation, further commands are under TLS layer>
	S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")		S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")
	C: a002 AUTHENTICATE "EXTERNAL-CHANNEL"		C: a002 AUTHENTICATE "EXTERNAL-CHANNEL"
	S: + "tls-unique rvOng1J3oo2oMQBc "		S: + "tls-unique "
	C: + ""		C: + ""
	S: a002 OK "Authenticated"		S: a002 OK "Authenticated"
	Note how the string ends with a " ", it needs to be present even if		Note how the string ends with a " ", it needs to be present even if
	the authorization identity is empty.		the authorization identity is empty.
	The second example shows use of EXTERNAL-CHANNEL with an		The second example shows use of EXTERNAL-CHANNEL with an
	authorization identity of "simon" bound to an external "tls-unique"		authorization identity of "simon" bound to an external "tls-unique"
	channel. In this example, the initial response is sent with the		channel. In this example, the initial response is sent with the
	client's request to initiate the authentication exchange. This saves		client's request to initiate the authentication exchange. This saves
	a round-trip.		a round-trip.
	S: * ACAP (SASL "DIGEST-MD5")		S: * ACAP (SASL "DIGEST-MD5")
	C: a001 STARTTLS		C: a001 STARTTLS
	S: a001 OK "Begin TLS negotiation now"		S: a001 OK "Begin TLS negotiation now"
	<TLS negotiation, further commands are under TLS layer>		<TLS negotiation, further commands are under TLS layer>
	S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")		S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")
	C: a002 AUTHENTICATE "EXTERNAL-CHANNEL" {31+}		C: a002 AUTHENTICATE "EXTERNAL-CHANNEL" {16+}
	C: tls-unique CI4WoQGSd7FdWPrw simon		C: tls-unique simon
	S: a002 NO "Cannot assume requested authorization identity"		S: a002 NO "Cannot assume requested authorization identity"
	Note how the server rejects the authentication attempt with an		Note how the server rejects the authentication attempt with an
	authorization-related error message. Presumably the client		authorization-related error message. Presumably the client
	credentials presented in the TLS session does not give the client		credentials presented in the TLS session does not give the client
	authority to assume the identity of "simon".		authority to assume the identity of "simon".
	4. Making Authorization Decisions		4. Making Authorization Decisions
	The server may use any mechanism to make authorization decisions.		The server may use any mechanism to make authorization decisions.
	skipping to change at page 8, line 8		skipping to change at page 8, line 37
	6. Security Considerations		6. Security Considerations
	The EXTERNAL-CHANNEL mechanism does not authenticate users itself, it		The EXTERNAL-CHANNEL mechanism does not authenticate users itself, it
	relies on implementation to perform the authentication as part of the		relies on implementation to perform the authentication as part of the
	external channel. Care must be taken to ensure that the client		external channel. Care must be taken to ensure that the client
	credential has been authenticated, rather than just blindly accepted		credential has been authenticated, rather than just blindly accepted
	as part of a leap-of-faith setup.		as part of a leap-of-faith setup.
	The security of external channel is critical to the security of this		The security of external channel is critical to the security of this
	mechanism. The connection between the authentication and the		mechanism. The connection between the authentication and the
	external channel is made via a channel binding, thus the security		external channel is made by sending the name of the channel, so the
	considerations related to channel bindings are also critical, see		security considerations related to channel bindings are also
	[RFC5056].		relevant, see [RFC5056].
	We claim that by appropriately using a channel binding an application
	can protect itself from the attacks in [MITM]. To guarantee this
	property, the derived data is only to be used for the intended
	purpose.
	7. Acknowledgements		7. Acknowledgements
	The EXTERNAL-CHANNEL mechanism, and significant amount of text in		The EXTERNAL-CHANNEL mechanism, and significant amount of text in
	this document, is based on the EXTERNAL mechanism in Appendix A of		this document, is based on the EXTERNAL mechanism in Appendix A of
	SASL [RFC4422].		SASL [RFC4422].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 4234, October 2005.
	[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and		[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
	Security Layer (SASL)", RFC 4422, June 2006.		Security Layer (SASL)", RFC 4422, June 2006.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure		[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", RFC 5056, November 2007.		Channels", RFC 5056, November 2007.
			[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", STD 68, RFC 5234, January 2008.
	8.2. Informative References		8.2. Informative References
	[RFC2244] Newman, C. and J. Myers, "ACAP -- Application		[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
	Configuration Access Protocol", RFC 2244, November 1997.		Configuration Access Protocol", RFC 2244, November 1997.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,		[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
	"Using the Secure Remote Password (SRP) Protocol for TLS		"Using the Secure Remote Password (SRP) Protocol for TLS
	Authentication", RFC 5054, November 2007.		Authentication", RFC 5054, November 2007.
	[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport		[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
	Layer Security (TLS) Authentication", RFC 5081,		Layer Security (TLS) Authentication", RFC 5081,
	November 2007.		November 2007.
	[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
	in Tunneled Authentication",
	WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
	Author's Address		Author's Address
	Simon Josefsson		Simon Josefsson
	SJD		SJD AB
	Email: simon@josefsson.org		Email: simon@josefsson.org
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 32 change blocks.
	79 lines changed or deleted		71 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/