< draft-ietf-sasl-rfc2222bis-14.txt		draft-ietf-sasl-rfc2222bis-15.txt >
	INTERNET-DRAFT A. Melnikov, Ed.		INTERNET-DRAFT A. Melnikov, Ed.
	Intended Category: Standards Track ISODE Limited		Intended Category: Standards Track ISODE Limited
	Expires in six months K. Zeilenga, Ed.		Expires: July 2006 K. Zeilenga, Ed.
	Obsoletes: RFC 2222 OpenLDAP Project		Obsoletes: RFC 2222 OpenLDAP Project
	17 November 2005		23 January 2006
	Simple Authentication and Security Layer (SASL)		Simple Authentication and Security Layer (SASL)
	<draft-ietf-sasl-rfc2222bis-14.txt>		<draft-ietf-sasl-rfc2222bis-15.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware have		applicable patent or other IPR claims of which he or she is aware have
	been or will be disclosed, and any of which he or she becomes aware		been or will be disclosed, and any of which he or she becomes aware
	will be disclosed, in accordance with Section 6 of BCP 79.		will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 material		time. It is inappropriate to use Internet-Drafts as reference material
	or to cite them other than as "work in progress."		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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2006). All Rights Reserved.
	Please see the Full Copyright section near the end of this document		Please see the Full Copyright section near the end of this document
	for more information.		for more information.
	Abstract		Abstract
	The Simple Authentication and Security Layer (SASL) is a framework for		The Simple Authentication and Security Layer (SASL) is a framework for
	providing authentication and data security services in		providing authentication and data security services in
	connection-oriented protocols via replaceable mechanisms. It provides		connection-oriented protocols via replaceable mechanisms. It provides
	a structured interface between protocols and mechanisms. The		a structured interface between protocols and mechanisms. The
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	an implementation is a local matter.		an implementation is a local matter.
	However, conceptually, SASL framework involves two identities:		However, conceptually, SASL framework involves two identities:
	1) an identity associated with the authentication credentials		1) an identity associated with the authentication credentials
	(termed the authentication identity), and		(termed the authentication identity), and
	2) an identity to act as (termed the authorization identity).		2) an identity to act as (termed the authorization identity).
	SASL mechanism specifications describe the credential form(s) (e.g.,		SASL mechanism specifications describe the credential form(s) (e.g.,
	X.509 certificates, Kerberos tickets, simple username/password) used		X.509 certificates, Kerberos tickets, simple username/password) used
	to authenticate the client, including (where appropriate) the syntax		to authenticate the client, including (where appropriate) the syntax
	and semantics of associated authentication identities. SASL protocol		and semantics of authentication identities carried in the credentials.
	specifications describe the identity form(s) used in authorization		SASL protocol specifications describe the identity form(s) used in
	and, in particular, prescribe the syntax and semantics of the		authorization and, in particular, prescribe the syntax and semantics
	authorization identity character string to be transferred by		of the authorization identity character string to be transferred by
	mechanisms.		mechanisms.
	The client provides its credentials which (implicitly or explicitly)		The client provides its credentials (which include or imply an
	include an authentication identity and, optionally, a character string		authentication identity) and, optionally, a character string
	representing the requested authorization identity as part of the SASL		representing the requested authorization identity as part of the SASL
	exchange. When this character string is omitted or empty, the client		exchange. When this character string is omitted or empty, the client
	is requesting to act as the identity associated with the credentials		is requesting to act as the identity associated with the credentials
	(e.g., the user is requesting to act as the authentication identity).		(e.g., the user is requesting to act as the authentication identity).
	The server is responsible for verifying the client's credentials and		The server is responsible for verifying the client's credentials and
	verifying that the client is allowed to act as the authorization		verifying that the identity it associates with the client's
	identity. A SASL exchange fails if either (or both) of these		credentials (e.g., the authentication identity) is allowed to act as
	verifications fails. (The SASL exchange may fail for other reasons,		the authorization identity. A SASL exchange fails if either (or both)
	such as service authorization failure.)		of these verifications fails. (The SASL exchange may fail for other
			reasons, such as service authorization failure.)
	However, the precise form(s) of the authentication identities (used		However, the precise form(s) of the authentication identities (used
	within the server in its verifications, or otherwise) and the precise		within the server in its verifications, or otherwise) and the precise
	form(s) of the authorization identities (used in making authorization		form(s) of the authorization identities (used in making authorization
	decisions, or otherwise) is beyond the scope of SASL and this		decisions, or otherwise) is beyond the scope of SASL and this
	specification. In some circumstances, the precise identity forms used		specification. In some circumstances, the precise identity forms used
	in some context outside of the SASL exchange may be dictated by other		in some context outside of the SASL exchange may be dictated by other
	specifications. For instance, an identity assumption authorization		specifications. For instance, an identity assumption authorization
	(proxy authorization) policy specification may dictate how		(proxy authorization) policy specification may dictate how
	authentication and authorization identities are represented in policy		authentication and authorization identities are represented in policy
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 14 ¶
	S: Initial challenge		S: Initial challenge
	C: Initial response		C: Initial response
	<additional challenge/response messages>		<additional challenge/response messages>
	S: Additional data challenge		S: Additional data challenge
	C: Empty Response		C: Empty Response
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Where mechanisms specify the first data sent in the exchange is from		Where mechanisms specify the first data sent in the exchange is from
	the client to the server and additional data is sent to the client		the client to the server and additional data is sent to the client
	along with indicating a successful outcome, and the protocol provides		along with indicating a successful outcome, and the protocol provides
	fields supporting both, the exchange can be shorted by two		fields supporting both, then the exchange takes two fewer round-trips:
	round-trips:
	C: Request authentication exchange + Initial response		C: Request authentication exchange + Initial response
	<additional challenge/response messages>		<additional challenge/response messages>
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	with additional data with success		with additional data with success
	instead of:		instead of:
	C: Request authentication exchange		C: Request authentication exchange
	S: Empty Challenge		S: Empty Challenge
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	function.		function.
	Specifications are encouraged to prescribe use of existing		Specifications are encouraged to prescribe use of existing
	authorization identity forms as well as existing string		authorization identity forms as well as existing string
	representations, such as simple user names [RFC4013].		representations, such as simple user names [RFC4013].
	Where the specification does not precisely prescribe how identities		Where the specification does not precisely prescribe how identities
	in SASL relate to identities used elsewhere in the protocol, for		in SASL relate to identities used elsewhere in the protocol, for
	instance in access control policy statements, it may be appropriate		instance in access control policy statements, it may be appropriate
	for the protocol to provide a facility by which the client can		for the protocol to provide a facility by which the client can
	discover information (such as the representation of the		discover information (such as the representation of the identity
	authentication identity used in making access control decisions)		used in making access control decisions) about established
	about established identities for these uses.		identities for these uses.
	5) Detail any facility the protocol provides that allows the client		5) Detail any facility the protocol provides that allows the client
	and/or server to abort authentication exchange (see Section 3.5).		and/or server to abort authentication exchange (see Section 3.5).
	Protocols which support multiple authentications typically allow a		Protocols which support multiple authentications typically allow a
	client to abort an on-going authentication exchange by initiating a		client to abort an on-going authentication exchange by initiating a
	new authentication exchange. Protocols which do not support		new authentication exchange. Protocols which do not support
	multiple authentications may require the client to close the		multiple authentications may require the client to close the
	connection and start over to abort an on-going authentication		connection and start over to abort an on-going authentication
	exchange.		exchange.
	skipping to change at page 16, line 28 ¶		skipping to change at page 16, line 28 ¶
	SASL mechanism specifications MUST supply the following information:		SASL mechanism specifications MUST supply the following information:
	1) The name of the mechanism (see Section 3.1). This name MUST be		1) The name of the mechanism (see Section 3.1). This name MUST be
	registered as discussed in Section 7.1.		registered as discussed in Section 7.1.
	2) A definition of the server-challenges and client-responses of the		2) A definition of the server-challenges and client-responses of the
	authentication exchange, as well as:		authentication exchange, as well as:
	a) An indication whether mechanism is client-first, variable, or		a) An indication whether mechanism is client-first, variable, or
	server-first. If a SASL mechanism is defined as client-first		server-first. If a SASL mechanism is defined as client-first
	and the client does not send an initial response, then the first		and the client does not send an initial response in the
	server challenge MUST be empty (the EXTERNAL mechanism is an		authentication request, then the first server challenge MUST be
	example of this case). If a SASL mechanism is defined as		empty (the EXTERNAL mechanism is an example of this case). If a
	variable, then the specification needs to state how the server		SASL mechanism is defined as variable, then the specification
	behaves when the initial client response is omitted (the		needs to state how the server behaves when the initial client
			response in the authentication request is omitted (the
	DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case).		DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case).
	If a SASL mechanism is defined as server-first then the client		If a SASL mechanism is defined as server-first then the client
	MUST NOT send an initial client response (the CRAM-MD5 mechanism		MUST NOT send an initial client response in the authentication
	[CRAM-MD5] is an example of this case).		request (the CRAM-MD5 mechanism [CRAM-MD5] is an example of this
			case).
	b) An indication whether the server is expected to provide		b) An indication whether the server is expected to provide
	additional data when indicating a successful outcome. If so, if		additional data when indicating a successful outcome. If so, if
	the server sends the additional data as a challenge, the		the server sends the additional data as a challenge, the
	specification MUST indicate the response to this challenge is an		specification MUST indicate the response to this challenge is an
	empty response.		empty response.
	SASL mechanisms SHOULD be designed to minimize the number of		SASL mechanisms SHOULD be designed to minimize the number of
	challenges and responses necessary to complete the exchange.		challenges and responses necessary to complete the exchange.
	skipping to change at page 19, line 10 ¶		skipping to change at page 19, line 13 ¶
	When the client selects a SASL security layer with at least integrity		When the client selects a SASL security layer with at least integrity
	protection, this protect serves as a counter-measure against an active		protection, this protect serves as a counter-measure against an active
	attacker hijacking the connection and modifying protocol data sent		attacker hijacking the connection and modifying protocol data sent
	after establishment of the security layer. Implementations should		after establishment of the security layer. Implementations should
	close the connection when the security services in an SASL security		close the connection when the security services in an SASL security
	layer report protocol data report lack of data integrity.		layer report protocol data report lack of data integrity.
	6.1.2. Downgrade Attacks		6.1.2. Downgrade Attacks
	It is important that any security-sensitive protocol negotiations be		It is important that any security-sensitive protocol negotiations be
	performed after installation of security layer with data integrity		performed after installation of a security layer with data integrity
	protection. Protocols should be designed such that negotiations		protection. Protocols should be designed such that negotiations
	performed prior to this installation should be revalidated after		performed prior to this installation should be revalidated after
	installation is complete. Negotiation of the SASL mechanism is		installation is complete. Negotiation of the SASL mechanism is
	security-sensitive.		security-sensitive.
	When a client negotiates the authentication mechanism with the server		When a client negotiates the authentication mechanism with the server
	and/or other security features, it is possible for an active attacker		and/or other security features, it is possible for an active attacker
	to cause a party to use the least secure security services available.		to cause a party to use the least secure security services available.
	For instance, an attacker can modify the server-advertised mechanism		For instance, an attacker can modify the server-advertised mechanism
	list or can modify client-advertised security feature list within a		list or can modify client-advertised security feature list within a
	skipping to change at page 31, line 42 ¶		skipping to change at page 31, line 44 ¶
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Full Copyright		Full Copyright
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	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
End of changes. 13 change blocks.
	28 lines changed or deleted		30 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/