draft-josefsson-sasl-external-channel-01.txt		draft-josefsson-sasl-external-channel-02.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Intended status: Standards Track April 14, 2009		Intended status: Standards Track April 14, 2009
	Expires: October 16, 2009		Expires: October 16, 2009
	SASL Mechanism for External Authentication using a Named Channel:		SASL Mechanism Family for External Authentication: EXTERNAL-*
	EXTERNAL-CHANNEL		draft-josefsson-sasl-external-channel-02
	draft-josefsson-sasl-external-channel-01
	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
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 2, line 13		skipping to change at page 2, line 11
	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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		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 client authentication in the
	the Simple Authentication and Security Layer (SASL) framework by re-		Simple Authentication and Security Layer (SASL) framework by
	using an external security layer (such as the Transport Layer		referring to the end-user authentication provided by an external
	Security (TLS) protocol) that may have already completed end-user		security layer. We specify a SASL mechanism family EXTERNAL-* and
	authentication. In comparison with the existing EXTERNAL mechanism,		one instance EXTERNAL-TLS that rely on the Transport Layer Security
	this mechanism alleviates the a priori assumptions made by the design		(TLS) protocol. This mechanism differs to the existing EXTERNAL
	of the EXTERNAL mechanism. This mechanism transfers an identifier of		mechanism by alleviating the a priori assumptions that servers and
	the external channel to be used explicitly.		clients needs somehow negotiate out of band which secure channel that
			is intended. This document also discuss the implementation of
			authorization decisions.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Technical Specification . . . . . . . . . . . . . . . . . . . . 4		2. Specification of EXTERNAL-* Mechanism Family . . . . . . . . . 4
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Specification of EXTERNAL-TLS Mechanism . . . . . . . . . . . . 6
	4. Making Authorization Decisions . . . . . . . . . . . . . . . . 7		4. Making Authorization Decisions . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
			9.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	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 [RFC5246] 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 impacted		between the server administration and client user. This has impacted
	the interoperability of the EXTERNAL mechanism.		the interoperability of the EXTERNAL mechanism.
	The EXTERNAL-CHANNEL mechanism, specified in this document, is		The EXTERNAL-* mechanism family, 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		provides a way for the client to provide an identifier of the
	external channel that provides the user credentials. The intention		external channel that is intended to provide the user credentials.
	is that the server need not rely on a priori arrangement to identify		The intention is that the server need not rely on a priori
	the secure channel that was used, but can automatically find the		arrangement to identify the secure channel that was used, but can
	intended channel and re-use its credentials for the SASL		automatically find the intended channel and re-use its credentials
	authentication.		for the SASL authentication. Further, upon successful
			authentication, the client knows that the server used credentials
			from the indicated security channel.
	In the EXTERNAL-CHANNEL mechanism, the external channel is identified		In the EXTERNAL-* mechanism family, the external channel is
	using the "Channel binding unique prefix" string as defined in		identified through the SASL mechanism name.
	[RFC5056].
	2. Technical Specification		2. Specification of EXTERNAL-* Mechanism Family
	The name of this mechanism is "EXTERNAL-CHANNEL".		The name of the mechanism family is "EXTERNAL-".
	The mechanism does not provide a security layer. It provides similar		The mechanism family does not provide a security layer. It provides
	functionality by relying on an external channel.		similar functionality by relying on an external channel.
	The mechanism is capable of transferring a channel name and an		The mechanism is capable of transferring an authorization identity
	authorization identity string. If the authorization identity string		string. If the authorization identity string is empty, the client is
	is empty, the client is requesting to act as the identity the server		requesting to act as the identity the server has associated with the
	has associated with the client's credentials. If the authorization		client's credentials. If the authorization identity string is non-
	identity string is non-empty, the client is requesting to act as the		empty, the client is requesting to act as the identity represented by
	identity represented by the string. The channel name cannot be		the string.
	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 name,		The client sends the initial response containing a UTF-8 [RFC3629]
	and a UTF-8 [RFC3629] encoding of the requested authorization		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) [RFC5234] notation.		Backus-Naur Form (ABNF) [RFC5234] notation.
	external-initial-resp = cb-name " " authz-id-string		external-initial-resp = authz-id-string
	cb-name = 1*( US-ASCII / "." / "-")
	;; Based on RFC 5056: "There is no naming convention for channel
	;; bindings: any string composed of US-ASCII alphanumeric
	;; characters, period ('.'), and dash ('-') will suffice."
	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 external security channel to use is implied by the SASL mechanism
			name.
	- the cb-name denote an (to the server implementation) unknown or		The exchange fails if
	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 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,
	skipping to change at page 6, line 10		skipping to change at page 6, line 4
	- 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,
	- the client provided a non-empty authorization identity string		- the client provided a non-empty authorization identity string
	representing an identity that the client is not allowed to act as, or		representing an identity that the client is not allowed to act as, or
	- the server is unwilling or unable to provide service to the client		- the server is unwilling or unable to provide service to the client
	for any other reason.		for any other reason.
	Otherwise the exchange is successful. When indicating a successful		Otherwise the exchange is successful. When indicating a successful
	outcome, additional data is not provided.		outcome, additional data is not provided.
	3. Examples		3. Specification of EXTERNAL-TLS Mechanism
	This section provides examples of EXTERNAL-CHANNEL authentication
	exchanges. The examples are intended to help the readers understand
	the above text. The examples are not definitive. The Application
	Configuration Access Protocol (ACAP) [RFC2244] is used in the
	examples because ACAP sends the SASL tokens without additional
	encoding.
	The first example shows use of EXTERNAL-CHANNEL with an empty
	authorization identity and an external "tls-unique" channel. In this
	example, the initial response is not sent in the client's request to
	initiate the authentication exchange.
	S: * ACAP (SASL "DIGEST-MD5")
	C: a001 STARTTLS
	S: a001 OK "Begin TLS negotiation now"
	<TLS negotiation, further commands are under TLS layer>
	S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")
	C: a002 AUTHENTICATE "EXTERNAL-CHANNEL"
	S: + "tls-unique "
	C: + ""
	S: a002 OK "Authenticated"
	Note how the string ends with a " ", it needs to be present even if
	the authorization identity is empty.
	The second example shows use of EXTERNAL-CHANNEL with an
	authorization identity of "simon" bound to an external "tls-unique"
	channel. In this example, the initial response is sent with the
	client's request to initiate the authentication exchange. This saves
	a round-trip.
	S: * ACAP (SASL "DIGEST-MD5")		The EXTERNAL-TLS mechanism uses client credentials established by the
	C: a001 STARTTLS		outer TLS [RFC5246] channel. Only the inner-most TLS channel is
	S: a001 OK "Begin TLS negotiation now"		intended. For example, if an application opens up a TLS channel and
	<TLS negotiation, further commands are under TLS layer>		starts SASL negotiation, and if that communication happens to be sent
	S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")		over a TLS-based VPN, the credentials for the TLS-based VPN is not
	C: a002 AUTHENTICATE "EXTERNAL-CHANNEL" {16+}		considered.
	C: tls-unique simon
	S: a002 NO "Cannot assume requested authorization identity"
	Note how the server rejects the authentication attempt with an		The server MUST NOT advertise the EXTERNAL-TLS mechanism if the
	authorization-related error message. Presumably the client		client did not provided any supported form of client-side
	credentials presented in the TLS session does not give the client		authentication in the TLS channel, e.g., X.509 client certificate,
	authority to assume the identity of "simon".		OpenPGP client key [RFC5081], or SRP [RFC5054]. The client MUST only
			request the EXTERNAL-TLS if it wishes to re-use the TLS client
			credentials for the SASL application.
	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.
	For illustration, we want to give some ideas on how this may work in		For illustration, we want to give some ideas on how this may work in
	practice. This section is not normative.		practice. This section is not normative.
	Typically the external channel will not use authentication identities		Typically external channels will not use authentication identities
	that can be used by the application protocol that uses the SASL		that can be used by the application protocol that uses an instance of
	EXTERNAL-CHANNEL mechanism. Thus, a mapping is normally required.		the SASL EXTERNAL-* mechanism. Thus, a mapping is normally required.
	There may be mappings from the external credential to a set of		There may be mappings from the external credential to a set of
	permitted identifiers, and a "default" identifier can be provided in		permitted identifiers, and a "default" identifier can be provided in
	the mapping table if the client do not specify a particular		the mapping table if the client do not specify a particular
	authorization identity.		authorization identity.
	For example, when mapping from X.509 credentials used in TLS		For example, when mapping from X.509 credentials used in TLS
	connections to simple usernames, a table stored on the server can		connections to simple usernames, a table stored on the server can
	contain hex-encoded hashes of client X.509 certificates and a set of		contain hex-encoded hashes of client X.509 certificates and a set of
	usernames.		usernames.
	skipping to change at page 8, line 13		skipping to change at page 7, line 22
	set of permitted usernames, such as the following table.		set of permitted usernames, such as the following table.
	0424D4EE81A0E3D119C6F835EDA21E94B565716F simon jas admin		0424D4EE81A0E3D119C6F835EDA21E94B565716F simon jas admin
	A4D94E92B0986AB5EE9DCD755DE249965B0358A2 werner		A4D94E92B0986AB5EE9DCD755DE249965B0358A2 werner
	90A79E2FC6F4AAB5B604974FE15DD857B15C37D1 nikos		90A79E2FC6F4AAB5B604974FE15DD857B15C37D1 nikos
	When SRP authentication with TLS [RFC5054] is used, the username		When SRP authentication with TLS [RFC5054] is used, the username
	provided may be the same as the application username, and no mapping		provided may be the same as the application username, and no mapping
	would be necessary.		would be necessary.
	5. IANA Considerations		5. Examples
			This section provides examples of EXTERNAL-TLS authentication
			exchanges. The examples are intended to help the readers understand
			the above text. The examples are not definitive. The Application
			Configuration Access Protocol (ACAP) [RFC2244] is used in the
			examples because ACAP sends the SASL tokens without additional
			encoding.
			The first example shows use of EXTERNAL-TLS with an empty
			authorization identity. In this example, the initial response is not
			sent in the client's request to initiate the authentication exchange.
			S: * ACAP (SASL "GSSAPI")
			C: a001 STARTTLS
			S: a001 OK "Begin TLS negotiation now"
			<TLS negotiation, further commands are under TLS layer>
			S: * ACAP (SASL "GSSAPI" "PLAIN" "EXTERNAL-TLS")
			C: a002 AUTHENTICATE "EXTERNAL-TLS"
			S: + ""
			C: + ""
			S: a002 OK "Authenticated"
			The second example shows use of EXTERNAL-TLS with an authorization
			identity of "simon". In this example, the initial response is sent
			with the client's request to initiate the authentication exchange.
			This saves a round-trip.
			S: * ACAP (SASL "GSSAPI")
			C: a001 STARTTLS
			S: a001 OK "Begin TLS negotiation now"
			<TLS negotiation, further commands are under TLS layer>
			S: * ACAP (SASL "GSSAPI" "PLAIN" "EXTERNAL-TLS")
			C: a002 AUTHENTICATE "EXTERNAL-TLS" {5+}
			C: simon
			S: a002 NO "Cannot assume requested authorization identity"
			Note how the server rejects the authentication attempt with an
			authorization-related error message. Presumably the client
			credentials presented in the TLS session does not give the client
			authority to assume the identity of "simon".
			6. IANA Considerations
	The IANA is request to add to the SASL mechanisms registry the		The IANA is request to add to the SASL mechanisms registry the
	following entry.		following entry.
	Subject: Registration of SASL mechanism EXTERNAL-CHANNEL		Subject: Registration of SASL mechanism family EXTERNAL-*
	SASL mechanism name (or prefix for the family): EXTERNAL-CHANNEL		SASL family name (or prefix for the family): EXTERNAL-
	Security considerations: See security considerations in RFC XXXX.		Security considerations: [THIS-DOC]
	Published specification (recommended): RFC XXXX.		Published specification (recommended): [THIS-DOC]
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Simon Josefsson <simon@josefsson.org>		Simon Josefsson <simon@josefsson.org>
	Intended usage: COMMON		Intended usage: COMMON
	Owner/Change controller: Simon Josefsson <simon@josefsson.org>		Owner/Change controller: Simon Josefsson <simon@josefsson.org>
	6. Security Considerations		7. Security Considerations
	The EXTERNAL-CHANNEL mechanism does not authenticate users itself, it		The security of external channel is critical to the security of this
	relies on implementation to perform the authentication as part of the		mechanism. It is important that the client authentication that
	external channel. Care must be taken to ensure that the client		occurs in the outer security channel is cryptographically bound to
			the confidentiality or integrity services that protects the security
			channel.
			The EXTERNAL-* mechanism family does not authenticate users itself,
			it relies on implementation to perform the authentication as part of
			the 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		8. Acknowledgements
	mechanism. The connection between the authentication and the
	external channel is made by sending the name of the channel, so the
	security considerations related to channel bindings are also
	relevant, see [RFC5056].
	7. Acknowledgements
	The EXTERNAL-CHANNEL mechanism, and significant amount of text in		The EXTERNAL-* mechanism family, 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		9. References
	8.1. Normative References		9.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.
	[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.
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", RFC 5056, November 2007.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	8.2. Informative References		9.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.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] 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.
End of changes. 29 change blocks.
	125 lines changed or deleted		128 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/