draft-josefsson-sasl-external-channel-03.txt		draft-josefsson-sasl-external-channel.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Intended status: Standards Track April 18, 2009		Intended status: Standards Track May 25, 2009
	Expires: October 20, 2009		Expires: November 26, 2009
	SASL Mechanism Family for External Authentication: EXTERNAL-*		SASL Mechanism Family for External Authentication: EXTERNAL-*
	draft-josefsson-sasl-external-channel-03		draft-josefsson-sasl-external-channel-04
	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 1, line 42		skipping to change at page 1, line 42
	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 October 20, 2009.		This Internet-Draft will expire on November 26, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 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
	skipping to change at page 5, line 40		skipping to change at page 5, line 40
	;; 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 external security channel to use is implied by the SASL mechanism		The external security channel to use is implied by the SASL mechanism
	name.		name. The channel has to be uniquely identifiable at both cliend and
			server side. This means that mechanisms registered in this family
			MUST detail which channel should be chosen if there are layered
			channels of the same type.
	The exchange fails if		The exchange fails if
	- 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,
	- 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.
	skipping to change at page 9, line 9		skipping to change at page 9, line 12
	While this registration procedure does not require expert review,		While this registration procedure does not require expert review,
	authors of SASL mechanisms are encouraged to seek community review		authors of SASL mechanisms are encouraged to seek community review
	and comment whenever that is feasible. Authors may seek community		and comment whenever that is feasible. Authors may seek community
	review by posting a specification of their proposed mechanism as an		review by posting a specification of their proposed mechanism as an
	Internet-Draft. SASL mechanisms intended for widespread use should		Internet-Draft. SASL mechanisms intended for widespread use should
	be standardized through the normal IETF process, when appropriate.		be standardized through the normal IETF process, when appropriate.
	7. Security Considerations		7. Security Considerations
	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. It is important that the client authentication that		mechanism. It is important that the client authentication provided
	occurs in the outer security channel is cryptographically bound to		by the security channel is securely bound to any confidentiality or
	the confidentiality or integrity services that protects the security		integrity services that protects the security channel.
	channel.
	The EXTERNAL-* mechanism family does not authenticate clients itself,		The EXTERNAL-* mechanism family does not authenticate clients itself,
	it relies on implementation to perform the authentication as part of		it relies on implementation to perform the authentication as part of
	the external channel. Care must be taken to ensure that the client		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.
	8. Acknowledgements		8. Acknowledgements
	Significant amount of text in this document is copied from SASL		Significant amount of text in this document is copied from SASL
	skipping to change at page 10, line 5		skipping to change at page 9, line 48
	[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.
	[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.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	9.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
	(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.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
End of changes. 9 change blocks.
	13 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/