< draft-myers-auth-sasl-11.txt		draft-myers-auth-sasl-12.txt >
	Network Working Group J. Myers		Network Working Group J. Myers
	Internet Draft April 1997		Internet Draft September 1997
	Document: draft-myers-auth-sasl-11.txt		Document: draft-myers-auth-sasl-12.txt
	Simple Authentication and Security Layer (SASL)		Simple Authentication and Security Layer (SASL)
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its Areas,
	and its Working Groups. Note that other groups may also distribute		and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet Drafts.
	skipping to change at page 2, line ? ¶		skipping to change at page 2, line ? ¶
	1id-abstracts.txt listing contained in the Internet-Drafts Shadow		1id-abstracts.txt listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or		Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
	munnari.oz.au.		munnari.oz.au.
	A revised version of this draft document will be submitted to the RFC		A revised version of this draft document will be submitted to the RFC
	editor as a Proposed Standard for the Internet Community. Discussion		editor as a Proposed Standard for the Internet Community. Discussion
	and suggestions for improvement are requested. This document will		and suggestions for improvement are requested. This document will
	expire before December 1996. Distribution of this draft is		expire before December 1996. Distribution of this draft is
	unlimited.		unlimited.
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	1. Abstract		1. Abstract
	This document describes a method for adding authentication support to		This document describes a method for adding authentication support to
	connection-based protocols. To use this specification, a protocol		connection-based protocols. To use this specification, a protocol
	includes a command for identifying and authenticating a user to a		includes a command for identifying and authenticating a user to a
	server and for optionally negotiating protection of subsequent		server and for optionally negotiating protection of subsequent
	protocol interactions. If its use is negotiated, a security layer is		protocol interactions. If its use is negotiated, a security layer is
	inserted between the protocol and the connection. This document		inserted between the protocol and the connection. This document
	describes how a protocol specifies such a command, defines several		describes how a protocol specifies such a command, defines several
	mechanisms for use by the command, and defines the protocol used for		mechanisms for use by the command, and defines the protocol used for
	carrying a negotiated security layer over the connection.		carrying a negotiated security layer over the connection.
	2. Organization of this Document		2. Organization of this Document
	2.1. How to Read This Document		2.1. How to Read This Document
	This document is written to serve two different audiences, protocol		This document is written to serve two different audiences, protocol
	designers using this specification to support authentication in their		designers using this specification to support authentication in their
	protocol, and implementors of clients or servers for those protocols		protocol, and implementors of clients or servers for those protocols
	using this specification.		using this specification.
	The sections "Introduction and Overview", "Profiling requirements",		The sections "Introduction and Overview", "Profiling requirements",
	and "Security Considerations" cover issues that protocol designers		and "Security Considerations" cover issues that protocol designers
	need to understand and address in profiling this specification for		need to understand and address in profiling this specification for
	use in a specific protocol.		use in a specific protocol.
	Implementors of a protocol using this specification need the		Implementors of a protocol using this specification need the
	protocol-specific profiling information in addition to the		protocol-specific profiling information in addition to the
	information in this document.		information in this document.
	2.2. Conventions Used in this Document		2.2. Conventions Used in this Document
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively.		server respectively.
	The following terms are used in this document to signify the		The following terms are used in this document to signify the
	requirements of this specification.		requirements of this specification.
	1) MUST, or the adjective REQUIRED, means that the definition is an		1) MUST, or the adjective REQUIRED, means that the definition is an
	absolute requirement of the specification.		absolute requirement of the specification.
	2) MUST NOT that the definition is an absolute prohibition of the		2) MUST NOT that the definition is an absolute prohibition of the
	specification.		specification.
	3) SHOULD means that there may exist valid reasons in particular		3) SHOULD means that there may exist valid reasons in particular
	circumstances to ignore a particular item, but the full implications		circumstances to ignore a particular item, but the full implications
	MUST be understood and carefully weighed before choosing a different		MUST be understood and carefully weighed before choosing a different
	course.		course.
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	4) SHOULD NOT means that there may exist valid reasons in particular		4) SHOULD NOT means that there may exist valid reasons in particular
	circumstances when the particular behavior is acceptable or even		circumstances when the particular behavior is acceptable or even
	useful, but the full implications SHOULD be understood and the case		useful, but the full implications SHOULD be understood and the case
	carefully weighed before implementing any behavior described with		carefully weighed before implementing any behavior described with
	this label.		this label.
	5) MAY, or the adjective OPTIONAL, means that an item is truly		5) MAY, or the adjective OPTIONAL, means that an item is truly
	optional. One vendor may choose to include the item because a		optional. One vendor may choose to include the item because a
	particular marketplace requires it or because the vendor feels that		particular marketplace requires it or because the vendor feels that
	it enhances the product while another vendor may omit the same item.		it enhances the product while another vendor may omit the same item.
	An implementation which does not include a particular option MUST be		An implementation which does not include a particular option MUST be
	prepared to interoperate with another implementation which does		prepared to interoperate with another implementation which does
	include the option.		include the option.
	"Can" is used instead of "may" when referring to a possible		"Can" is used instead of "may" when referring to a possible
	circumstance or situation, as opposed to an optional facility of the		circumstance or situation, as opposed to an optional facility of the
	protocol.		protocol.
	2.3. Examples		2.3. Examples
	Examples in this document are for the IMAP profile [IMAP4] of this		Examples in this document are for the IMAP profile [IMAP4] of this
	specification. The base64 encoding of challenges and responses, as		specification. The base64 encoding of challenges and responses, as
	well as the "+ " preceding the responses are part of the IMAP4		well as the "+ " preceding the responses are part of the IMAP4
	profile, not part of the SASL specification itself.		profile, not part of the SASL specification itself.
	3. Introduction and Overview		3. Introduction and Overview
	The Simple Authentication and Security Layer (SASL) is a method for		The Simple Authentication and Security Layer (SASL) is a method for
	adding authentication support to connection-based protocols. To use		adding authentication support to connection-based protocols. To use
	this specification, a protocol includes a command for identifying and		this specification, a protocol includes a command for identifying and
	authenticating a user to a server and for optionally negotiating a		authenticating a user to a server and for optionally negotiating a
	security layer for subsequent protocol interactions.		security layer for subsequent protocol interactions.
	The command has a required argument identifying a SASL mechanism.		The command has a required argument identifying a SASL mechanism.
	SASL mechanisms are named by strings, from 1 to 20 characters in		SASL mechanisms are named by strings, from 1 to 20 characters in
	length, consisting of upper-case letters, digits, hyphens, and/or		length, consisting of upper-case letters, digits, hyphens, and/or
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	section "Registration procedures"		section "Registration procedures"
	If a server supports the requested mechanism, it initiates an		If a server supports the requested mechanism, it initiates an
	authentication protocol exchange. This consists of a series of		authentication protocol exchange. This consists of a series of
	server challenges and client responses that are specific to the		server challenges and client responses that are specific to the
	requested mechanism. The challenges and responses are defined by the		requested mechanism. The challenges and responses are defined by the
	mechanisms as binary tokens of arbitrary length. The protocol's		mechanisms as binary tokens of arbitrary length. The protocol's
	profile then specifies how these binary tokens are then encoded for		profile then specifies how these binary tokens are then encoded for
	transfer over the connection.		transfer over the connection.
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	After receiving the authentication command or any client response, a		After receiving the authentication command or any client response, a
	server may issue a challenge, indicate failure, or indicate		server may issue a challenge, indicate failure, or indicate
	completion. The protocol's profile specifies how the server		completion. The protocol's profile specifies how the server
	indicates which of the above it is doing.		indicates which of the above it is doing.
	After receiving a challenge, a client may issue a response or abort		After receiving a challenge, a client may issue a response or abort
	the exchange. The protocol's profile specifies how the client		the exchange. The protocol's profile specifies how the client
	indicates which of the above it is doing.		indicates which of the above it is doing.
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 44 ¶
	effect immediately following the last response of the authentication		effect immediately following the last response of the authentication
	exchange for data sent by the client and the completion indication		exchange for data sent by the client and the completion indication
	for data sent by the server. Once the security layer is in effect,		for data sent by the server. Once the security layer is in effect,
	the protocol stream is processed by the security layer into buffers		the protocol stream is processed by the security layer into buffers
	of cipher-text. Each buffer is transferred over the connection as a		of cipher-text. Each buffer is transferred over the connection as a
	stream of octets prepended with a four octet field in network byte		stream of octets prepended with a four octet field in network byte
	order that represents the length of the following buffer. The length		order that represents the length of the following buffer. The length
	of the cipher-text buffer must be no larger than the maximum size		of the cipher-text buffer must be no larger than the maximum size
	that was defined or negotiated by the other side.		that was defined or negotiated by the other side.
	4. Profiling requirements		4. Profiling requirements
	In order to use this specification, a protocol definition must supply		In order to use this specification, a protocol definition must supply
	the following information:		the following information:
	1. A service name, to be selected from the IANA registry of "service"		1. A service name, to be selected from the IANA registry of "service"
	elements for the GSSAPI host-based service name form. [GSSAPI]		elements for the GSSAPI host-based service name form. [GSSAPI]
	2. A definition of the command to initiate the authentication		2. A definition of the command to initiate the authentication
	protocol exchange. This command must have as a parameter the		protocol exchange. This command must have as a parameter the
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	mechanism name being selected by the client.		mechanism name being selected by the client.
	The command SHOULD have an optional parameter giving an initial		The command SHOULD have an optional parameter giving an initial
	response. This optional parameter allows the client to avoid a		response. This optional parameter allows the client to avoid a
	round trip when using a mechanism which is defined to have the		round trip when using a mechanism which is defined to have the
	client send data first. When this initial response is sent by the		client send data first. When this initial response is sent by the
	client and the selected mechanism is defined to have the server		client and the selected mechanism is defined to have the server
	start with an initial challenge, the command fails. See section		start with an initial challenge, the command fails. See section
	5.1 of this document for further information.		5.1 of this document for further information.
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	failure of the exchange, how the client aborts an exchange, and		failure of the exchange, how the client aborts an exchange, and
	how the exchange method interacts with any line length limits in		how the exchange method interacts with any line length limits in
	the protocol.		the protocol.
	4. Identification of the octet where any negotiated security layer		4. Identification of the octet where any negotiated security layer
	starts to take effect, in both directions.		starts to take effect, in both directions.
	5. A specification of how the authorization identity passed from the		5. A specification of how the authorization identity passed from the
	client to the server is to be interpreted.		client to the server is to be interpreted.
	5. Specific issues		5. Specific issues
	5.1. Client sends data first		5.1. Client sends data first
	Some mechanisms specify that the first data sent in the		Some mechanisms specify that the first data sent in the
	authentication protocol exchange is from the client to the server.		authentication protocol exchange is from the client to the server.
	If a protocol's profile permits the command which initiates an		If a protocol's profile permits the command which initiates an
	authentication protocol exchange to contain an initial client		authentication protocol exchange to contain an initial client
	response, this parameter SHOULD be used with such mechanisms.		response, this parameter SHOULD be used with such mechanisms.
	If the initial client response parameter is not given, or if a		If the initial client response parameter is not given, or if a
	protocol's profile does not permit the command which initiates an		protocol's profile does not permit the command which initiates an
	authentication protocol exchange to contain an initial client		authentication protocol exchange to contain an initial client
	response, then the server issues a challenge with no data. The		response, then the server issues a challenge with no data. The
	client's response to this challenge is then used as the initial		client's response to this challenge is then used as the initial
	client response. (The server then proceeds to send the next		client response. (The server then proceeds to send the next
	challenge, indicates completion, or indicates failure.)		challenge, indicates completion, or indicates failure.)
	5.2. Server returns success with additional data		5.2. Server returns success with additional data
	Some mechanisms may specify that server challenge data be sent to the		Some mechanisms may specify that server challenge data be sent to the
	client along with an indication of successful completion of the		client along with an indication of successful completion of the
	exchange. This data would, for example, authenticate the server to		exchange. This data would, for example, authenticate the server to
	the client.		the client.
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	If a protocol's profile does not permit this server challenge to be		If a protocol's profile does not permit this server challenge to be
	returned with a success indication, then the server issues the server		returned with a success indication, then the server issues the server
	challenge without an indication of successful completion. The client		challenge without an indication of successful completion. The client
	then responds with no data. After receiving this empty response, the		then responds with no data. After receiving this empty response, the
	server then indicates successful completion.		server then indicates successful completion.
	5.3. Multiple authentications		5.3. Multiple authentications
	Unless otherwise stated by the protocol's profile, only one		Unless otherwise stated by the protocol's profile, only one
	successful SASL negotiation may occur in a protocol session. In this		successful SASL negotiation may occur in a protocol session. In this
	case, once an authentication protocol exchange has successfully		case, once an authentication protocol exchange has successfully
	completed, further attempts to initiate an authentication protocol		completed, further attempts to initiate an authentication protocol
	exchange fail.		exchange fail.
	In the case that a profile explicitly permits multiple successful		In the case that a profile explicitly permits multiple successful
	SASL negotiations to occur, then in no case may multiple security		SASL negotiations to occur, then in no case may multiple security
	layers be simultaneously in effect. If a security layer is in effect		layers be simultaneously in effect. If a security layer is in effect
	and a subsequent SASL negotiation selects no security layer, the		and a subsequent SASL negotiation selects no security layer, the
	original security layer remains in effect. If a security layer is in		original security layer remains in effect. If a security layer is in
	effect and a subsequent SASL negotiation selects a second security		effect and a subsequent SASL negotiation selects a second security
	layer, then the second security layer replaces the first.		layer, then the second security layer replaces the first.
	6. Registration procedures		6. Registration procedures
	The following documents the procedure for registering new SASL		Registration of a SASL mechanism is done by filling in the template
	mechanism types.		in section 6.4 and sending it in to iana@isi.edu. IANA has the right
			to reject obviously bogus registrations, but will perform no review
			of clams made in the registration form.
			There is no naming convention for SASL mechanisms; any name that
			conforms to the syntax of a SASL mechanism name can be registered.
	While the registration procedures do not require it, authors of SASL		While the registration procedures do not require it, authors of SASL
	mechanisms are encouraged to seek community review and comment		mechanisms are encouraged to seek community review and comment
	whenever that is feasible. Authors may seek community review by		whenever that is feasible. Authors may seek community review by
	posting a specification of their proposed mechanism as an internet-		posting a specification of their proposed mechanism as an internet-
	draft. SASL mechanisms intended for widespread use should be		draft. SASL mechanisms intended for widespread use should be
	standardized through the normal IETF process, when appropriate.		standardized through the normal IETF process, when appropriate.
	6.1. Comments on SASL mechanism registrations		6.1. Comments on SASL mechanism registrations
	Comments on registered SASL mechanisms should first be sent to the		Comments on registered SASL mechanisms should first be sent to the
	"owner" of the mechanism. Submitters of comments may, after a		"owner" of the mechanism. Submitters of comments may, after a
	reasonable attempt to contact the owner, request IANA to attach their		reasonable attempt to contact the owner, request IANA to attach their
	comment to the SASL mechanism registration itself. If IANA approves		comment to the SASL mechanism registration itself. If IANA approves
	of this the comment will be made accessible in conjunction with the		of this the comment will be made accessible in conjunction with the
	SASL mechanism registration itself.		SASL mechanism registration itself.
			Internet DRAFT SASL September 9, 1997
	6.2. Location of Registered SASL Mechanism List		6.2. Location of Registered SASL Mechanism List
	SASL mechanism registrations will be posted in the anonymous FTP		SASL mechanism registrations will be posted in the anonymous FTP
	directory		directory
	"ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/" and		"ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/" and
	Internet DRAFT SASL May 27, 1997
	all registered SASL mechanisms will be listed in the periodically		all registered SASL mechanisms will be listed in the periodically
	issued "Assigned Numbers" RFC [currently RFC-1700]. The SASL		issued "Assigned Numbers" RFC [currently RFC-1700]. The SASL
	mechanism description and other supporting material may also be		mechanism description and other supporting material may also be
	published as an Informational RFC by sending it to		published as an Informational RFC by sending it to
	"rfc-editor@isi.edu" (please follow the instructions to RFC authors		"rfc-editor@isi.edu" (please follow the instructions to RFC authors
	[RFC-1543]).		[RFC-1543]).
	6.3. Change Control		6.3. Change Control
	Once a SASL mechanism registration has been published by IANA, the		Once a SASL mechanism registration has been published by IANA, the
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 5 ¶
	To: iana@isi.edu		To: iana@isi.edu
	Subject: Registration of SASL mechanism X		Subject: Registration of SASL mechanism X
	SASL mechanism name:		SASL mechanism name:
	Security considerations:		Security considerations:
	Published specification (optional, recommended):		Published specification (optional, recommended):
			Internet DRAFT SASL September 9, 1997
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Intended usage:		Intended usage:
	(One of COMMON, LIMITED USE or OBSOLETE)		(One of COMMON, LIMITED USE or OBSOLETE)
	Internet DRAFT SASL May 27, 1997
	Author/Change controller:		Author/Change controller:
	(Any other information that the author deems interesting may be		(Any other information that the author deems interesting may be
	added below this line.)		added below this line.)
	7. Mechanism definitions		7. Mechanism definitions
	The following mechanisms are hereby defined.		The following mechanisms are hereby defined.
	7.1. Kerberos version 4 mechanism		7.1. Kerberos version 4 mechanism
	The mechanism name associated with Kerberos version 4 is		The mechanism name associated with Kerberos version 4 is
	"KERBEROS_V4".		"KERBEROS_V4".
	The first challenge consists of a random 32-bit number in network		The first challenge consists of a random 32-bit number in network
	byte order. The client responds with a Kerberos ticket and an		byte order. The client responds with a Kerberos ticket and an
	authenticator for the principal "service.hostname@realm", where		authenticator for the principal "service.hostname@realm", where
	"service" is the service name specified in the protocol's profile,		"service" is the service name specified in the protocol's profile,
	"hostname" is the first component of the host name of the server with		"hostname" is the first component of the host name of the server with
	all letters in lower case, and where "realm" is the Kerberos realm of		all letters in lower case, and where "realm" is the Kerberos realm of
	skipping to change at page 8, line 49 ¶		skipping to change at page 9, line 4 ¶
	cipher-text buffer size the server is able to receive. The server		cipher-text buffer size the server is able to receive. The server
	must encrypt using DES ECB mode the 8 octets of data in the session		must encrypt using DES ECB mode the 8 octets of data in the session
	key and issue that encrypted data in a second challenge. The client		key and issue that encrypted data in a second challenge. The client
	considers the server authenticated if the first four octets of the		considers the server authenticated if the first four octets of the
	un-encrypted data is equal to one plus the checksum it previously		un-encrypted data is equal to one plus the checksum it previously
	sent.		sent.
	The client must construct data with the first four octets containing		The client must construct data with the first four octets containing
	the original server-issued checksum in network byte order, the fifth		the original server-issued checksum in network byte order, the fifth
	octet containing the bit-mask specifying the selected security layer,		octet containing the bit-mask specifying the selected security layer,
			Internet DRAFT SASL September 9, 1997
	the sixth through eighth octets containing in network byte order the		the sixth through eighth octets containing in network byte order the
	maximum cipher-text buffer size the client is able to receive, and		maximum cipher-text buffer size the client is able to receive, and
	the following octets containing the authorization identity. The		the following octets containing the authorization identity. The
	client must then append from one to eight zero-valued octets so that		client must then append from one to eight zero-valued octets so that
	the length of the data is a multiple of eight octets. The client must		the length of the data is a multiple of eight octets. The client must
	then encrypt using DES PCBC mode the data with the session key and		then encrypt using DES PCBC mode the data with the session key and
	Internet DRAFT SASL May 27, 1997
	respond with the encrypted data. The server decrypts the data and		respond with the encrypted data. The server decrypts the data and
	verifies the contained checksum. The server must verify that the		verifies the contained checksum. The server must verify that the
	principal identified in the Kerberos ticket is authorized to connect		principal identified in the Kerberos ticket is authorized to connect
	as that authorization identity. After this verification, the		as that authorization identity. After this verification, the
	authentication process is complete.		authentication process is complete.
	The security layers and their corresponding bit-masks are as follows:		The security layers and their corresponding bit-masks are as follows:
	1 No security layer		1 No security layer
	2 Integrity (krb_mk_safe) protection		2 Integrity (krb_mk_safe) protection
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	S: A001 OK Kerberos V4 authentication successful		S: A001 OK Kerberos V4 authentication successful
	S: * OK IMAP4 Server		S: * OK IMAP4 Server
	C: A001 AUTHENTICATE KERBEROS_V4		C: A001 AUTHENTICATE KERBEROS_V4
	S: + gcfgCA==		S: + gcfgCA==
	C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT		C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
	+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd		+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
	WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh		WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
	S: A001 NO Kerberos V4 authentication failed		S: A001 NO Kerberos V4 authentication failed
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	7.2. GSSAPI mechanism		7.2. GSSAPI mechanism
	The mechanism name associated with all mechanisms employing the		The mechanism name associated with all mechanisms employing the
	GSSAPI [GSSAPI] is "GSSAPI".		GSSAPI [GSSAPI] is "GSSAPI".
	7.2.1 Client side of authentication protocol exchange		7.2.1 Client side of authentication protocol exchange
	The client calls GSS_Init_sec_context, passing in 0 for		The client calls GSS_Init_sec_context, passing in 0 for
	input_context_handle (initially) and a targ_name equal to output_name		input_context_handle (initially) and a targ_name equal to output_name
	from GSS_Import_Name called with input_name_type of		from GSS_Import_Name called with input_name_type of
	GSS_C_NT_HOSTBASED_SERVICE and input_name_string of		GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	The server passes the initial client response to		The server passes the initial client response to
	GSS_Accept_sec_context as input_token, setting input_context_handle		GSS_Accept_sec_context as input_token, setting input_context_handle
	to 0 (initially). If GSS_Accept_sec_context returns		to 0 (initially). If GSS_Accept_sec_context returns
	GSS_S_CONTINUE_NEEDED, the server returns the generated output_token		GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
	to the client in challenge and passes the resulting response to		to the client in challenge and passes the resulting response to
	another call to GSS_Accept_sec_context, repeating the actions in this		another call to GSS_Accept_sec_context, repeating the actions in this
	paragraph.		paragraph.
	When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes		When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	the following actions: If the last call to GSS_Accept_sec_context		the following actions: If the last call to GSS_Accept_sec_context
	returned an output_token, the server returns it to the client in a		returned an output_token, the server returns it to the client in a
	challenge and expects a reply from the client with no data. Whether		challenge and expects a reply from the client with no data. Whether
	or not an output_token was returned (and after receipt of any		or not an output_token was returned (and after receipt of any
	response from the client to such an output_token), the server then		response from the client to such an output_token), the server then
	constructs 4 octets of data, with the first octet containing a bit-		constructs 4 octets of data, with the first octet containing a bit-
	mask specifying the security layers supported by the server and the		mask specifying the security layers supported by the server and the
	second through fourth octets containing in network byte order the		second through fourth octets containing in network byte order the
	maximum size output_token the server is able to receive. The server		maximum size output_token the server is able to receive. The server
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	The security layers and their corresponding bit-masks are as follows:		The security layers and their corresponding bit-masks are as follows:
	1 No security layer		1 No security layer
	2 Integrity protection.		2 Integrity protection.
	Sender calls GSS_Wrap with conf_flag set to FALSE		Sender calls GSS_Wrap with conf_flag set to FALSE
	4 Privacy protection.		4 Privacy protection.
	Sender calls GSS_Wrap with conf_flag set to TRUE		Sender calls GSS_Wrap with conf_flag set to TRUE
	Other bit-masks may be defined in the future; bits which are not		Other bit-masks may be defined in the future; bits which are not
	understood must be negotiated off.		understood must be negotiated off.
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	7.3. S/Key mechanism		7.3. S/Key mechanism
	The mechanism name associated with S/Key [SKEY] using the MD4 digest		The mechanism name associated with S/Key [SKEY] using the MD4 digest
	algorithm is "SKEY".		algorithm is "SKEY".
	The client sends an initial response with the authorization identity.		The client sends an initial response with the authorization identity.
	The server then issues a challenge which contains the decimal		The server then issues a challenge which contains the decimal
	sequence number followed by a single space and the seed string for		sequence number followed by a single space and the seed string for
	the indicated authorization identity. The client responds with the		the indicated authorization identity. The client responds with the
	one-time-password, as either a 64-bit value in network byte order or		one-time-password, as either a 64-bit value in network byte order or
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	The following is an S/Key login scenario in an IMAP4-like protocol		The following is an S/Key login scenario in an IMAP4-like protocol
	which has an optional "initial response" argument to the AUTHENTICATE		which has an optional "initial response" argument to the AUTHENTICATE
	command.		command.
	S: * OK IMAP4-Like Server		S: * OK IMAP4-Like Server
	C: A001 AUTHENTICATE SKEY bW9yZ2Fu		C: A001 AUTHENTICATE SKEY bW9yZ2Fu
	S: + OTUgUWE1ODMwOA==		S: + OTUgUWE1ODMwOA==
	C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==		C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
	S: A001 OK S/Key authentication successful		S: A001 OK S/Key authentication successful
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	7.4 External mechanism		7.4. External mechanism
	The mechanism name associated with external authentication is		The mechanism name associated with external authentication is
	"EXTERNAL".		"EXTERNAL".
	The client sends an initial response with the authorization identity.		The client sends an initial response with the authorization identity.
	The server uses information, external to SASL, to determine whether		The server uses information, external to SASL, to determine whether
	the client is authorized to authenticate as the authorization		the client is authorized to authenticate as the authorization
	identity. If the client is so authorized, the server indicates		identity. If the client is so authorized, the server indicates
	successful completion of the authentication exchange; otherwise the		successful completion of the authentication exchange; otherwise the
	server indicates failure.		server indicates failure.
	The system providing this external information may be, for example,		The system providing this external information may be, for example,
	IPsec or TLS.		IPsec or TLS.
	If the client sends the empty string as the authorization identity		If the client sends the empty string as the authorization identity
	(thus requesting the authorization identity be derived from the		(thus requesting the authorization identity be derived from the
	client's authentication credentials), the autorization identity is to		client's authentication credentials), the authorization identity is
	be derived from authentication credentials which exist in the system		to be derived from authentication credentials which exist in the
	which is providing the external authentication.		system which is providing the external authentication.
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	8. References		8. References
	[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",		[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
	RFC 1730, University of Washington, December 1994.		RFC 1730, University of Washington, December 1994.
	[GSSAPI] Linn, J., "Generic Security Service Application Program		[GSSAPI] Linn, J., "Generic Security Service Application Program
	Interface, Version 2", RFC 2078, January 1997		Interface, Version 2", RFC 2078, January 1997
	[RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543,		[RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543,
	October 1993		October 1993
	[SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC		[SKEY] Haller, Neil M. "The S/Key One-Time Password System", RFC
	1760, Bellcore, February 1995		1760, Bellcore, February 1995
	8. Security Considerations		9. Security Considerations
	Security issues are discussed throughout this memo.		Security issues are discussed throughout this memo.
	The mechanisms that support integrity protection are designed such		The mechanisms that support integrity protection are designed such
	that the negotiation of the security layer and authorization identity		that the negotiation of the security layer and authorization identity
	is integrity protected. When the client selects a security layer		is integrity protected. When the client selects a security layer
	with at least integrity protection, this protects against an active		with at least integrity protection, this protects against an active
	attacker hijacking the connection and modifying the authentication		attacker hijacking the connection and modifying the authentication
	exchange to negotiate a plaintext connection.		exchange to negotiate a plaintext connection.
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	obtain an authentication with weaker security properties by modifying		obtain an authentication with weaker security properties by modifying
	the SASL mechanism name and/or the challenges and responses.		the SASL mechanism name and/or the challenges and responses.
	Any protocol interactions prior to authentication are performed in		Any protocol interactions prior to authentication are performed in
	the clear and may be modified by an active attacker. In the case		the clear and may be modified by an active attacker. In the case
	where a client selects integrity protection, it is important that any		where a client selects integrity protection, it is important that any
	security-sensitive protocol negotiations be performed after		security-sensitive protocol negotiations be performed after
	authentication is complete. Protocols should be designed such that		authentication is complete. Protocols should be designed such that
	negotiations performed prior to authentication should be either		negotiations performed prior to authentication should be either
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	ignored or revalidated once authentication is complete.		ignored or revalidated once authentication is complete.
	9. Author's Address		10. Author's Address
	John G. Myers		John G. Myers
	220 Palo Alto Ave, Apt 102		Netscape Communications
	Palo Alto, CA 94301		501 E. Middlefield Road
			Mail Stop MV-029
			Mountain View, CA 94043-4042
	Email: jgmyers@netscape.com		Email: jgmyers@netscape.com
	Appendix A. Relation of SASL to Transport Security		Appendix A. Relation of SASL to Transport Security
	Questions have been raised about the relationship between SASL and		Questions have been raised about the relationship between SASL and
	various services (such as IPsec and TLS) which provide a secured		various services (such as IPsec and TLS) which provide a secured
	connection.		connection.
	Two of the key features of SASL are:		Two of the key features of SASL are:
	skipping to change at page 15, line 52 ¶		skipping to change at page 16, line 4 ¶
	Sometimes it is desired to enable within an existing connection the		Sometimes it is desired to enable within an existing connection the
	use of a security service which does not fit the SASL model. (TLS is		use of a security service which does not fit the SASL model. (TLS is
	an example of such a service.) This can be done by adding a command,		an example of such a service.) This can be done by adding a command,
	for example "STARTTLS", to the protocol. Such a command is outside		for example "STARTTLS", to the protocol. Such a command is outside
	the scope of SASL, and should be different from the command which		the scope of SASL, and should be different from the command which
	starts a SASL authentication protocol exchange.		starts a SASL authentication protocol exchange.
	In certain situations, it is reasonable to use SASL underneath one of		In certain situations, it is reasonable to use SASL underneath one of
	these Transport Security services. The transport service would		these Transport Security services. The transport service would
	secure the connection, either service would authenticate the client,		secure the connection, either service would authenticate the client,
	and SASL would negotiate the authorization identity. The SASL
	negotiation would be what moves the protocol from "unauthenticated"
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
			and SASL would negotiate the authorization identity. The SASL
			negotiation would be what moves the protocol from "unauthenticated"
	to "authenticated" state. The "EXTERNAL" SASL mechanism is		to "authenticated" state. The "EXTERNAL" SASL mechanism is
	explicitly intended to handle the case where the transport service		explicitly intended to handle the case where the transport service
	securies the connection and authenticates the client and SASL		secures the connection and authenticates the client and SASL
	negotiates the authorization identity.		negotiates the authorization identity.
	When using SASL underneath a sufficiently strong Transport Security		When using SASL underneath a sufficiently strong Transport Security
	service, a SASL security layer would most likely be redundant. The		service, a SASL security layer would most likely be redundant. The
	client and server would thus probably want to negotiate off the use		client and server would thus probably want to negotiate off the use
	of a SASL security layer.		of a SASL security layer.
	Internet DRAFT SASL May 27, 1997		Internet DRAFT SASL September 9, 1997
	TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss		Table of Contents
	Status of this Memo ............................................... i		Status of this Memo ............................................... i
	1. Abstract ..................................................... 2		1. Abstract .................................................... 2
	2. Organization of this Document ................................ 2		2. Organization of this Document ............................... 2
	2.1. How to Read This Document .................................... 2		2.1. How to Read This Document ................................... 2
	2.2. Conventions Used in this Document ............................ 2		2.2. Conventions Used in this Document ........................... 2
	2.3. Examples ..................................................... 3		2.3. Examples .................................................... 3
	3. Introduction and Overview .................................... 3		3. Introduction and Overview ................................... 3
	4. Profiling requirements ....................................... 4		4. Profiling requirements ...................................... 4
	5. Specific issues .............................................. 5		5. Specific issues ............................................. 5
	5.1. Client sends data first ...................................... 5		5.1. Client sends data first ..................................... 5
	5.2. Server returns success with additional data .................. 5		5.2. Server returns success with additional data ................. 5
	5.3. Multiple authentications ..................................... 6		5.3. Multiple authentications .................................... 6
	6. Registration procedures ...................................... 6		6. Registration procedures ..................................... 6
	6.1. Comments on SASL mechanism registrations ..................... 6		6.1. Comments on SASL mechanism registrations .................... 6
	6.2. Location of Registered SASL Mechanism List .................. 6		6.2. Location of Registered SASL Mechanism List .................. 7
	6.3. Change Control .............................................. 7		6.3. Change Control .............................................. 7
	6.4. Registration Template ....................................... 7		6.4. Registration Template ....................................... 7
	7. Mechanism definitions ........................................ 8		7. Mechanism definitions ....................................... 8
	7.1. Kerberos version 4 mechanism ................................. 8		7.1. Kerberos version 4 mechanism ................................ 8
	7.2. GSSAPI mechanism ............................................. 10		7.2. GSSAPI mechanism ............................................ 10
	7.2.1 Client side of authentication protocol exchange ............. 10		7.2.1 Client side of authentication protocol exchange ............. 10
	7.2.2 Server side of authentication protocol exchange ............. 10		7.2.2 Server side of authentication protocol exchange ............. 10
	7.2.3 Security layer .............................................. 11		7.2.3 Security layer .............................................. 11
	7.3. S/Key mechanism .............................................. 12		7.3. S/Key mechanism ............................................. 12
	7.4 External mechanism ............................................ 13		7.4. External mechanism .......................................... 13
	8. References ................................................... 14		8. References .................................................. 14
	8. Security Considerations ....................................... 14		9. Security Considerations ..................................... 14
	9. Author's Address ............................................. 15		10. Author's Address ............................................ 15
	Appendix A. Relation of SASL to Transport Security ................ 15		Appendix A. Relation of SASL to Transport Security ................ 15
End of changes. 51 change blocks.
	77 lines changed or deleted		83 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/