draft-ietf-sasl-gs2-04.txt		draft-ietf-sasl-gs2-05.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: June 10, 2007		Expires: July 13, 2007
	Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family		Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	draft-ietf-sasl-gs2-04		draft-ietf-sasl-gs2-05
	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		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		have 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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	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		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 June 10, 2007.		This Internet-Draft will expire on July 13, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2007).
	Abstract		Abstract
	This document describes how to use a Generic Security Service		This document describes how to use a Generic Security Service
	Application Program Interface (GSS-API) mechanism in the the Simple		Application Program Interface (GSS-API) mechanism in the the Simple
	Authentication and Security Layer (SASL) framework. This is done by		Authentication and Security Layer (SASL) framework. This is done by
	defining a new SASL mechanism family, called GS2. This mechanism		defining a new SASL mechanism family, called GS2. This mechanism
	family offers a number of improvements over the previous SASL/GSS-API		family offers a number of improvements over the previous SASL/GSS-API
	mechanism: it is more general, uses fewer messages for the		mechanism: it is more general, uses fewer messages for the
	authentication phase in some cases, and supports a SASL-specific		authentication phase in some cases, and supports a SASL-specific
	skipping to change at page 3, line 19		skipping to change at page 3, line 19
	3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 6		3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 6
	3.2. Computing mechanism names manually . . . . . . . . . . . . 6		3.2. Computing mechanism names manually . . . . . . . . . . . . 6
	3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. SASL Authentication Exchange Message Format . . . . . . . . . 8		4. SASL Authentication Exchange Message Format . . . . . . . . . 8
	4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8		4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9		4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9		4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10		4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11		4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11
	4.3.1. Client first GSS_Wrap input . . . . . . . . . . . . . 12		4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12
	4.3.2. Server last GSS_Wrap input . . . . . . . . . . . . . . 13		4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12
	4.3.3. Server first GSS_Wrap input . . . . . . . . . . . . . 13		4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13
	4.3.4. Client last GSS_Wrap input . . . . . . . . . . . . . . 14		4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 13
			4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14
	5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15		5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16		6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16
	7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20		7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20
	8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21		8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21
	9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22		9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22
	9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22		9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 24		10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24
	10.1. The interoperability problem . . . . . . . . . . . . . . . 24		11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25
	10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 24
	10.3. Additional recommendations . . . . . . . . . . . . . . . . 24
	11. Mechanisms that negotiate other mechanisms . . . . . . . . . . 25
	11.1. The interoperability problem . . . . . . . . . . . . . . . 25		11.1. The interoperability problem . . . . . . . . . . . . . . . 25
	11.2. Security problem . . . . . . . . . . . . . . . . . . . . . 25		11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25
	11.3. Resolving the problems . . . . . . . . . . . . . . . . . . 25		11.3. Additional recommendations . . . . . . . . . . . . . . . . 25
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 27		12.1. The interoperability problem . . . . . . . . . . . . . . . 26
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28		12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 29		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	15.2. Informative References . . . . . . . . . . . . . . . . . . 29		14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
	Intellectual Property and Copyright Statements . . . . . . . . . . 32		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
			16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
			16.2. Informative References . . . . . . . . . . . . . . . . . . 31
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
			Intellectual Property and Copyright Statements . . . . . . . . . . 34
	1. Introduction		1. Introduction
	Generic Security Service Application Program Interface (GSS-API) [3]		Generic Security Service Application Program Interface (GSS-API) [3]
	is a framework that provide security services to applications.		is a framework that provide security services to applications.
	Simple Authentication and Security Layer (SASL) [2] is a framework to		Simple Authentication and Security Layer (SASL) [2] is a framework to
	provide authentication and security layers for connection based		provide authentication and security layers for connection based
	protocols. This document describe how to use a GSS-API mechanism in		protocols. This document describe how to use a GSS-API mechanism in
	a connection-based protocol using the SASL framework.		a connection-based protocol using the SASL framework.
	skipping to change at page 4, line 32		skipping to change at page 4, line 32
	the other protocol is more widely deployed. There are		the other protocol is more widely deployed. There are
	interoperability concerns by having the same GSS-API mechanism		interoperability concerns by having the same GSS-API mechanism
	available under more than one SASL mechanism name, see the section		available under more than one SASL mechanism name, see the section
	"Interoperability with the GSSAPI mechanism" below.		"Interoperability with the GSSAPI mechanism" below.
	There are interoperability and security concerns if this SASL		There are interoperability and security concerns if this SASL
	mechanism is used together with a GSS-API mechanism that negotiate		mechanism is used together with a GSS-API mechanism that negotiate
	other GSS-API mechanisms (such as SPNEGO [11]), see the section		other GSS-API mechanisms (such as SPNEGO [11]), see the section
	"Mechanisms that negotiate other mechanisms" below.		"Mechanisms that negotiate other mechanisms" below.
			There are interoperability and security concerns with GSSAPI
			mechanism that do not provide integrity, see the section "Non-
			integrity capable GSS-API mechanisms" below.
	SASL mechanism names starting with "GS2-" are reserved for SASL		SASL mechanism names starting with "GS2-" are reserved for SASL
	mechanisms which conform to this document.		mechanisms which conform to this document.
	The IESG is considered to be the owner of all SASL mechanisms which		The IESG is considered to be the owner of all SASL mechanisms which
	conform to this document. This does not necessarily imply that the		conform to this document. This does not necessarily imply that the
	IESG is considered to be the owner of the underlying GSSAPI		IESG is considered to be the owner of the underlying GSSAPI
	mechanism.		mechanism.
	2. Conventions used in this document		2. Conventions used in this document
	skipping to change at page 8, line 40		skipping to change at page 8, line 40
	octet (32 bit) integer encoded in network byte order, that indicate		octet (32 bit) integer encoded in network byte order, that indicate
	the length of the "Context token" and "Wrap token" fields,		the length of the "Context token" and "Wrap token" fields,
	respectively. A length of 0 means that a particular field is not		respectively. A length of 0 means that a particular field is not
	present.		present.
	The "Context token" field, if present, contain a GSS-API context		The "Context token" field, if present, contain a GSS-API context
	establishment token generated by GSS_Init_sec_context or		establishment token generated by GSS_Init_sec_context or
	GSS_Accept_sec_context.		GSS_Accept_sec_context.
	The "Wrap token" field, if present, contain the output generated by		The "Wrap token" field, if present, contain the output generated by
	GSS_Wrap.		the GS2_Wrap function.
	The fields need not be aligned to 32-bit a boundary. There is no		The fields need not be aligned to 32-bit a boundary. There is no
	padding between fields.		padding between fields.
	Messages shorter than or equal to 8 octets are invalid. From that it		Messages shorter than or equal to 8 octets are invalid. From that it
	follows that at least one of the "Context token length" and the "Wrap		follows that at least one of the "Context token length" and the "Wrap
	token length" integers MUST be non-zero in a particular message. If		token length" integers MUST be non-zero in a particular message. If
	the sum of the length integers is longer than the entire message		the sum of the length integers is longer than the entire message
	size, minus 8 octets for the length fields, the message is invalid.		size, minus 8 octets for the length fields, the message is invalid.
	skipping to change at page 9, line 14		skipping to change at page 9, line 14
	Conforming implementations MUST NOT send additional data after the		Conforming implementations MUST NOT send additional data after the
	above message syntax, and MUST ignore additional data. To		above message syntax, and MUST ignore additional data. To
	illustrate, implementations MUST NOT assume that the last "Wrap token		illustrate, implementations MUST NOT assume that the last "Wrap token
	length" octets of the packet correspond to the "Wrap token", because		length" octets of the packet correspond to the "Wrap token", because
	that would be incorrect if the packet contained additional data not		that would be incorrect if the packet contained additional data not
	described by this document.		described by this document.
	4.2. Context Token Field		4.2. Context Token Field
	The format of the "Context token" field inside the SASL token are		The format of the "Context token" field inside the SASL token is
	defined by the GSS-API specifications, and the data is computed by		defined by each GSS-API mechanism, and the data is computed by (for
	the GSS_Init_sec_context (for the client) and GSS_Accept_sec_context		the client) GSS_Init_sec_context and (for the server)
	(for the server) functions.		GSS_Accept_sec_context.
	4.2.1. Client side		4.2.1. Client side
	The client calls GSS_Init_sec_context, passing in		The client calls GSS_Init_sec_context, passing in
	input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of		input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of
	the GSSAPI mechanism for which this SASL mechanism is registered, the		the GSSAPI mechanism for which this SASL mechanism is registered, the
	chan_binding is set to NULL, and targ_name equal to output_name from		chan_binding is set to NULL, and targ_name equal to output_name from
	GSS_Import_Name called with input_name_type of		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
	"service@hostname" where "service" is the service name specified in		"service@hostname" where "service" is the service name specified in
	the protocol's profile, and "hostname" is the fully qualified host		the protocol's profile, and "hostname" is the fully qualified host
	name of the server.		name of the server.
	(*) - Clients MAY use name types other than		(*) - Clients MAY use name types other than
	GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but		GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but
	only when they have a priori knowledge that the servers support		only when they have a priori knowledge that the servers support
	alternate name types. Otherwise clients MUST use		alternate name types. Otherwise clients MUST use
	GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.		GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.
	When calling the GSS_Init_sec_context the client MUST pass the		When calling the GSS_Init_sec_context the client SHOULD pass the
	integ_req_flag of TRUE. If the client intends to request a security		integ_req_flag of TRUE, but MAY set it to FALSE (see section 10
	layer, it MUST also supply to the GSS_Init_sec_context a		below). If the client intends to request a security layer, it MUST
	mutual_req_flag of TRUE, and a sequence_req_flag of TRUE. If the		also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE,
	client will be requesting a security layer providing confidentiality		and a sequence_req_flag of TRUE. If the client will be requesting a
	protection, it MUST also supply to the GSS_Init_sec_context a		security layer providing confidentiality protection, it MUST also
	conf_req_flag of TRUE.		supply to the GSS_Init_sec_context a conf_req_flag of TRUE.
	The client then responds with any resulting output_token.		The client then responds with any resulting output_token.
	If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the		If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
	client expect the server to issue a token in a subsequent challenge		client expect the server to issue a token in a subsequent challenge
	or as additional information to the outcome of the authentication.		or as additional information to the outcome of the authentication.
	The client pass the context token to another call to		The client pass the context token to another call to
	GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE		GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE
	is returned or authentication is aborted.		is returned or authentication is aborted.
	skipping to change at page 11, line 31		skipping to change at page 11, line 31
	permitted by the server's security policy.		permitted by the server's security policy.
	4.3. Wrap Token Field		4.3. Wrap Token Field
	The Wrap token field MUST NOT be sent or received before the		The Wrap token field MUST NOT be sent or received before the
	PROT_READY flag is set locally (by GSS_Init_sec_context or		PROT_READY flag is set locally (by GSS_Init_sec_context or
	Gss_Accept_sec_context), or if the PROT_READY flag is never set,		Gss_Accept_sec_context), or if the PROT_READY flag is never set,
	before the context has been fully established. The Wrap token field		before the context has been fully established. The Wrap token field
	does not have to be present directly when the PROT_READY flag is set.		does not have to be present directly when the PROT_READY flag is set.
	During any exchange, exactly one Wrap token field is sent in each		During any exchange, exactly one Wrap token field is sent in each
	direction. The input to the GSS_Wrap function MUST follow the format		direction. The GS2_Wrap function is defined below, and its inputs
	described below. If not exactly one Wrap token is received by the		MUST follow the format described below. If not exactly one Wrap
	client and by the server, the authentication MUST fail.		token is received by the client and by the server, the authentication
			MUST fail.
	If PROT_READY is never set by GSS_Init_sec_context or		If PROT_READY is never set by GSS_Init_sec_context or
	GSS_Accept_sec_context, the flag is implied by successful context		GSS_Accept_sec_context, the flag is implied by successful context
	negotiation. This is for GSS-API v1 mechanisms that do not support		negotiation. This is for GSS-API v1 mechanisms that do not support
	PROT_READY. This may result in a SASL token consisting of a context		PROT_READY, or for GSS-API mechanism that do not provide per-message
			protection. This may result in a SASL token consisting of a context
	token length of 0 and a Wrap token.		token length of 0 and a Wrap token.
	The entity that sends its first Wrap token will have to specify a		The entity that sends the first Wrap token will have to specify a
	bitmap of supported and preferred quality of protection schemes. The		bitmap of supported and preferred quality of protection schemes. The
	entity that replies to the Wrap tokens will pick a scheme, based on		entity that replies to the Wrap tokens will pick a scheme, based on
	the bitmask and local policy. The quality of protection values are		the bitmask and local policy. The quality of protection values are
	defined in section 9.		defined in section 9.
	Two pairs of input formats to the GSS_Wrap function are defined. The		Two pairs of input formats to the GS2_Wrap function are defined. The
	first pair is used when the client sends the GSS_Wrap token first and		first pair is used when the client sends the Wrap token first and the
	the server responds. The other pair is used when the server sends		server responds. The other pair is used when the server sends the
	the GSS_Wrap token first and the client responds.		Wrap token first and the client responds.
	The inputs below are passed to GSS_Wrap with conf_flag set to FALSE,		The inputs below are passed to GS2_Wrap, and the output is used as
	and the Wrap token will be the generated output_message.		the Wrap token value.
	Some fields in the input formats are optional, indicated by brackets		Some fields in the input formats are optional, indicated by brackets
	("[" and "]") and explained by the text below.		("[" and "]") and explained by the text below.
	4.3.1. Client first GSS_Wrap input		4.3.1. The GS2_Wrap function
	The input to GSS_Wrap when the client sends a Wrap token field first		The GS2_Wrap function have two implementations, and which one is used
			depends on whether the negotiated GSS-API context supports per-
			message protection. When a context is successfully negotiated (i.e.,
			when GSS_S_COMPLETE is returned from, for clients,
			GSS_Init_sec_context, or, for servers, GSS_Accept_sec_context) and
			the output variable integ_avail is FALSE, then GSS_Wrap cannot be
			used and instead we define GS2_Wrap to be the identity function.
			When integ_avail is negotiated TRUE, the GS2_Wrap is identical to
			calling the GSS_Wrap function with conf_flag set to FALSE and using
			the generated output_message as the output data.
			4.3.2. Client first GS2_Wrap input
			The input to GS2_Wrap when the client sends a Wrap token field first
	is as follows.		is as follows.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| client_qops | client_maxbuf |		| client_qops | client_maxbuf |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| channel_binding_length |		| channel_binding_length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|[client_cbqops]| [channel_binding_data] /		|[client_cbqops]| [channel_binding_data] /
	skipping to change at page 13, line 10		skipping to change at page 13, line 24
	The optional field "channel_binding_data" is present only if		The optional field "channel_binding_data" is present only if
	"channel_binding_length" is non-zero, and contain the actual channel		"channel_binding_length" is non-zero, and contain the actual channel
	binding data.		binding data.
	The optional field "authzid" contain the authorization identity. The		The optional field "authzid" contain the authorization identity. The
	authorization identity is encoded using UTF-8 [5]. The authorization		authorization identity is encoded using UTF-8 [5]. The authorization
	identity is not terminated with the NUL (U+0000) character. Servers		identity is not terminated with the NUL (U+0000) character. Servers
	MUST validate that the authorization identity is valid UTF-8.		MUST validate that the authorization identity is valid UTF-8.
	4.3.2. Server last GSS_Wrap input		4.3.3. Server last GS2_Wrap input
	The input to GSS_Wrap when the server sends a Wrap token field, after		The input to GS2_Wrap when the server sends a Wrap token field, after
	receiving the Wrap token in the previous section from the client, is		receiving the Wrap token in the previous section from the client, is
	as follows.		as follows.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| server_qop | server_maxbuf |		| server_qop | server_maxbuf |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The "server_qop" field integer indicate the selected quality of		The "server_qop" field integer indicate the selected quality of
	skipping to change at page 13, line 34		skipping to change at page 13, line 48
	9.		9.
	The "server_maxbuf" field indicate the maximum protected data buffer		The "server_maxbuf" field indicate the maximum protected data buffer
	size the server can receive in network byte order. It MUST be 0 if		size the server can receive in network byte order. It MUST be 0 if
	the server doesn't advertise support for any security layer, the		the server doesn't advertise support for any security layer, the
	client MUST verify this. Small values can make it impossible for the		client MUST verify this. Small values can make it impossible for the
	client to send any protected message to the server, due to the		client to send any protected message to the server, due to the
	overhead added by GSS_Wrap, and the client MAY reject the		overhead added by GSS_Wrap, and the client MAY reject the
	authentication if it detects this situation.		authentication if it detects this situation.
	4.3.3. Server first GSS_Wrap input		4.3.4. Server first GS2_Wrap input
	The input to GSS_Wrap when the server sends the Wrap token first is		The input to GS2_Wrap when the server sends the Wrap token first is
	as follows.		as follows.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| server_qops | server_maxbuf |		| server_qops | server_maxbuf |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|[server_cbqops]| [channel_binding_data] /		|[server_cbqops]| [channel_binding_data] /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 14, line 12		skipping to change at page 14, line 27
	The "server_maxbuf" is the same as above.		The "server_maxbuf" is the same as above.
	The optional field "server_cbqops" indicate the server's preferred		The optional field "server_cbqops" indicate the server's preferred
	quality of protection if channel binding negotiation succeeds. The		quality of protection if channel binding negotiation succeeds. The
	quality of protection values are defined in section 9.		quality of protection values are defined in section 9.
	The optional field "channel_binding_data" contain the actual channel		The optional field "channel_binding_data" contain the actual channel
	binding data.		binding data.
	4.3.4. Client last GSS_Wrap input		4.3.5. Client last GS2_Wrap input
	The input to GSS_Wrap when the clients sends a Wrap token field,		The input to GS2_Wrap when the clients sends a Wrap token field,
	after receiving the Wrap token in the previous section from the		after receiving the Wrap token in the previous section from the
	server, is as follows.		server, is as follows.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| client_qop | client_maxbuf |		| client_qop | client_maxbuf |
	/ [authzid] |		/ [authzid] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 16, line 15		skipping to change at page 16, line 15
	6. Protocol Overview		6. Protocol Overview
	This section describe several high-level protocol exchanges. The		This section describe several high-level protocol exchanges. The
	descriptions do not assume any properties of the actual GSS-API		descriptions do not assume any properties of the actual GSS-API
	mechanism. Protocol profiles, GSS-API mechanism specific behaviour,		mechanism. Protocol profiles, GSS-API mechanism specific behaviour,
	and to some extent implementation and policy choices, will dictate		and to some extent implementation and policy choices, will dictate
	which packets are sent in what order. The protocol exchanges are		which packets are sent in what order. The protocol exchanges are
	examples and other exchanges are permitted and will occur.		examples and other exchanges are permitted and will occur.
	An informal pseudo-language is used to describe the packets sent		An informal pseudo-language is used to describe the packets sent
	below. In particular, when GSS_Wrap() is mentioned below, it refer		below. GS2_Wrap refer to the operation of calling GS2_Wrap on the
	to the operation of calling GSS_Wrap on the indicated fields,		indicated fields, formatted in the structures described earlier.
	formatted in the structures described earlier.		GSS_Init_sec_context and GSS_Accept_sec_context refer to the context
			token generated by calling the respective function. The GS2 SASL
			Message is denoted as [Context_token, Wrap_token], and the length
			fields are not mentioned.
	An authentication exchange using GS2 may look like:		An authentication exchange using GS2 may look like:
	C: Request authentication exchange		C: Request authentication exchange
	S: Send [length=0] token		S: Send ["", ""] token
	C: Send [length, GSS_Init_sec_context] token		C: Send [GSS_Init_sec_context, ""] token
	...		...
	S: After PROT_READY is set,		S: After PROT_READY is set,
	send [length, GSS_Accept_sec_context,		send [GSS_Accept_sec_context,
	GSS_Wrap(server_qops | server_maxbuf]		wrap_length, GS2_Wrap(server_qops | server_maxbuf]
	...		...
	C: After PROT_READY is set,		C: After PROT_READY is set,
	send [length, GSS_Init_sec_context,		send [GSS_Init_sec_context,
	GSS_Wrap (client_qop | client_maxbuf | authzid)]		wrap_length, GS2_Wrap (client_qop | client_maxbuf |
	S: Send [length, GSS_Accept_sec_context] token		authzid)]
	C: Send [length, GSS_Init_sec_context] token		S: Send [GSS_Accept_sec_context, ""] token
			C: Send [GSS_Init_sec_context, ""] token
	...		...
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Because GSS-API authentication is initiated by the client, the length		Because GSS-API authentication is initiated by the client, the length
	field will be 0 in the initial token from the server to the client		field will be 0 in the initial token from the server to the client
	when the protocol profile does not support additional information to		when the protocol profile does not support additional information to
	be sent together with the authentication request.		be sent together with the authentication request.
	The next example illustrate when the client sends its Wrap token		The next example illustrate when the client sends its Wrap token
	first.		first.
	C: Request authentication exchange		C: Request authentication exchange
	S: Send [length=0] token		S: Send ["", ""] token
	C: Send [length, GSS_Init_sec_context] token		C: Send [GSS_Init_sec_context, ""] token
	...		...
	C: After PROT_READY is set,		C: After PROT_READY is set,
	send [length, GSS_Init_sec_context,		send [GSS_Init_sec_context,
	GSS_Wrap(client_qops | client_maxbuf |		GS2_Wrap(client_qops | client_maxbuf |
	channel_binding_length=0 | authzid)]		channel_binding_length=0 | authzid)]
	...		...
	S: After PROT_READY is set,		S: After PROT_READY is set,
	send [length, GSS_Accept_sec_context,		send [GSS_Accept_sec_context,
	GSS_Wrap (server_qop | server_maxbuf)]		GS2_Wrap (server_qop | server_maxbuf)]
	C: Send [length, GSS_Init_sec_context] token		C: Send [GSS_Init_sec_context, ""] token
	S: Send [length, GSS_Accept_sec_context] token		S: Send [GSS_Accept_sec_context, ""] token
	...		...
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	If the protocol profile support the optional initial client response,		If the protocol profile support the optional initial client response,
	the first empty message can be optimized away, and then the protocol		the first empty message can be optimized away, and then the protocol
	exchange will look like:		exchange will look like:
	C: Request authentication exchange and		C: Request authentication exchange and
	send [length, GSS_Init_sec_context] token		send [GSS_Init_sec_context, ""] token
	S: Send [length, GSS_Accept_sec_context] token		S: Send [GSS_Accept_sec_context, ""] token
	...		...
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	If the protocol profile can also send additional information when		If the protocol profile can also send additional information when
	indicating the outcome of the authentication, then the protocol		indicating the outcome of the authentication, then the protocol
	exchange will look like:		exchange will look like:
	C: Request authentication exchange and		C: Request authentication exchange and
	send [length, GSS_Init_sec_context] token		send [GSS_Init_sec_context, ""] token
	S: Send [length, GSS_Accept_sec_context] token		S: Send [GSS_Accept_sec_context, ""] token
	...		...
	C: Send [length, GSS_Init_sec_context] token		C: Send [GSS_Init_sec_context, ""] token
	S: Indicate successful authentication and		S: Indicate successful authentication and
	send [length, GSS_Accept_sec_context] token		send [GSS_Accept_sec_context, ""] token
	as additional information.		as additional information.
	If the PROT_READY flag is never set by the GSS-API mechanism, the		If the PROT_READY flag is never set by the GSS-API mechanism, the
	GSS_Wrap message will be sent after the context has been established.		GS2_Wrap message will be sent after the context has been established.
	The protocol may look like:		The protocol may look like:
	C: Request authentication exchange		C: Request authentication exchange
	...		...
	S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs		S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
	a token, send [length, context token,		a token, send ["", GS2_Wrap(server_qops | server_maxbuf)]
	GSS_Wrap(server_qops | server_maxbuf)]
	C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not		C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
	output a token, send		output a token, send
	[length=0, context token,		["", GS2_Wrap(client_qop | client_maxbuf |
	GSS_Wrap(client_qop | client_maxbuf |
	channel_binding_length=0 | authzid)]		channel_binding_length=0 | authzid)]
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Alternatively, if the client finishes first, it may look like:		Alternatively, if the client finishes first, it may look like:
	C: Request authentication exchange		C: Request authentication exchange
	...		...
	C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a		C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
	token, send [length, context token,		token, send ["", GS2_Wrap(client_qops | client_maxbuf |
	GSS_Wrap(client_qops | client_maxbuf |
	channel_binding_length=0 | authzid)]		channel_binding_length=0 | authzid)]
	S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not		S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
	output a token, send [length, context token,		output a token, send ["", GS2_Wrap(server_qop | server_maxbuf |
	GSS_Wrap(server_qop | server_maxbuf |
	channel_binding_length=0)]		channel_binding_length=0)]
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Adding channel bindings to the last examples, gives the following		Adding channel bindings to the last examples, gives the following
	situation. Here the client request confidentiality for the		complex situation. Here the client request confidentiality for the
	application data if channel binding fails but no SASL security layer		application data if channel binding fails but no SASL security layer
	if channel binding negotiation succeeds:		if channel binding negotiation succeeds:
	C: Request authentication exchange		C: Request authentication exchange
	...		...
	C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a		C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
	token, send [length, context token,		token, send [GSS_Init_sec_context,
	GSS_Wrap(client_qops=0x04 | client_maxbuf |		GS2_Wrap(client_qops=0x04 | client_maxbuf |
	channel_binding_length=n |		channel_binding_length=n |
	client_cbqops=0x01 | channel_binding_data |		client_cbqops=0x01 | channel_binding_data |
	authzid)]		authzid)]
	S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not		S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
	output a token, send [length, context token,		output a token, send ["",
	GSS_Wrap(server_qop | server_maxbuf |		GS2_Wrap(server_qop | server_maxbuf |
	channel_binding_length=0)]		channel_binding_length=0)]
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	If the protocol support initial data from the client, and the		If the protocol support initial data from the client, and the
	PROT_READY flag is set in the client after the first call to		PROT_READY flag is set in the client after the first call to
	GSS_Init_sec_context, and the server can send additional data to the		GSS_Init_sec_context, and the server can send additional data to the
	client when indicating successful authentication, the following		client when indicating successful authentication, the following
	protocol exchange will occur.		protocol exchange will occur.
	C: Request authentication exchange and		C: Request authentication exchange and
	send [length, GSS_Init_sec_context,		send [GSS_Init_sec_context,
	GSS_Wrap (client_qops | client_maxbuf |		GS2_Wrap (client_qops | client_maxbuf |
	channel_binding_length=0 | authzid)] token		channel_binding_length=0 | authzid)] token
	S: Indicate successful authentication and		S: Indicate successful authentication and
	send [length, GSS_Accept_sec_context,		send [GSS_Accept_sec_context,
	GSS_Wrap(server_qop | server_maxbuf)] token		GS2_Wrap(server_qop | server_maxbuf)] token
	as additional information.		as additional information.
	The last example illustrate the optimal (round-trip wise)		The last example illustrate the optimal (round-trip wise)
	authentication possible using this protocol.		authentication possible using this protocol.
	7. Authentication Conditions		7. Authentication Conditions
	Authentication MUST NOT succeed if any one of the following		Authentication MUST NOT succeed if any one of the following
	conditions are true:		conditions are true:
	skipping to change at page 24, line 5		skipping to change at page 24, line 5
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	When confidentiality is negotiated the octet will encode an integer 4		When confidentiality is negotiated the octet will encode an integer 4
	as follows.		as follows.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|0|0|0|0|0|1|0|0|		|0|0|0|0|0|1|0|0|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	10. Interoperability with the SASL "GSSAPI" mechanism		10. Non-integrity capable GSS-API mechanisms
			Mechanisms that do not support integrity can be used with GS2, but
			some security features cannot be provided, in particular including
			channel bindings, security layers, and integrity protection of the
			authorization identity.
			Channel bindings and security layers MUST NOT be negotiated when the
			GSS-API mechanism do not support integrity. It should also be
			understood that the authorization identity is not integrity
			protected.
			Whether a mechanism supports integrity or not, for the purpose of
			GS2, is decided by whether the integ_avail output variable from
			GSS_Init_sec_context (for clients) and GSS_Accept_sec_context (for
			servers). If integ_avail is FALSE, integrity is not supported.
			There is a potential interoperability problem if a client call
			GSS_Init_sec_context with integ_req_flag of TRUE and the context
			negotiation fails because the mechanism (due to design, the
			capability of the credentials, or policy) cannot provide per-message
			protection. Calling GSS_Init_sec_context with a FALSE integ_req_flag
			instead is not optimal, since a mechanism may then negotiate less
			security than it would have otherwise done.
			It is RECOMMENDED that implementations only ever call
			GSS_Init_sec_context with a integ_req_flag of FALSE when it knows
			that the particular GSS-API mechanism will not be able to negotiate
			per-message protection services.
			Implementations MAY have a policy to disallow non-integrity capable
			mechanisms, and always call GSS_Init_sec_context with the
			integ_req_flag set to TRUE.
			11. Interoperability with the SASL "GSSAPI" mechanism
	The Kerberos V5 GSS-API [10] mechanism is currently used in SASL		The Kerberos V5 GSS-API [10] mechanism is currently used in SASL
	under the name "GSSAPI", see GSSAPI mechanism [12]. The Kerberos V5		under the name "GSSAPI", see GSSAPI mechanism [12]. The Kerberos V5
	mechanism may also be used with the GS2 family. This causes an		mechanism may also be used with the GS2 family. This causes an
	interopability problem, which is discussed and resolved below.		interopability problem, which is discussed and resolved below.
	10.1. The interoperability problem		11.1. The interoperability problem
	If a client (or server) only support Kerberos V5 under the "GSSAPI"		If a client (or server) only support Kerberos V5 under the "GSSAPI"
	name and the server (or client) only support Kerberos V5 under the		name and the server (or client) only support Kerberos V5 under the
	GS2 family, the authentication negotiation will fail.		GS2 family, the authentication negotiation will fail.
	10.2. Resolving the problem		11.2. Resolving the problem
	If the Kerberos V5 mechanism is supported under GS2 in a server, the		If the Kerberos V5 mechanism is supported under GS2 in a server, the
	server SHOULD also support Kerberos V5 through the "GSSAPI"		server SHOULD also support Kerberos V5 through the "GSSAPI"
	mechanism, to avoid interoperability problems with older clients.		mechanism, to avoid interoperability problems with older clients.
	Reasons for violating this recommendation may include security		Reasons for violating this recommendation may include security
	considerations regarding the absent features in the GS2 mechanism.		considerations regarding the absent features in the GS2 mechanism.
	The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which		The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
	could enable certain tunnel attacks [17].		could enable certain tunnel attacks [17].
	10.3. Additional recommendations		11.3. Additional recommendations
	It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism		It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
	rather than through the "GSSAPI" mechanism, if both are available,		rather than through the "GSSAPI" mechanism, if both are available,
	because of the additional features in the GS2 mechanism.		because of the additional features in the GS2 mechanism.
	11. Mechanisms that negotiate other mechanisms		12. Mechanisms that negotiate other mechanisms
	A GSS-API mechanism that negotiate other mechanisms interact badly		A GSS-API mechanism that negotiate other mechanisms interact badly
	with the SASL mechanism negotiation. There are two problems. The		with the SASL mechanism negotiation. There are two problems. The
	first is an interoperability problem and the second is a security		first is an interoperability problem and the second is a security
	concern. The problems are described and resolved below.		concern. The problems are described and resolved below.
	11.1. The interoperability problem		12.1. The interoperability problem
	If a client implement GSS-API mechanism X, potentially negotiated		If a client implement GSS-API mechanism X, potentially negotiated
	through a GSS-API mechanism Y, and the server also implement GSS-API		through a GSS-API mechanism Y, and the server also implement GSS-API
	mechanism X negotiated through a GSS-API mechanism Z, the		mechanism X negotiated through a GSS-API mechanism Z, the
	authentication negotiation will fail.		authentication negotiation will fail.
	11.2. Security problem		12.2. Security problem
	If a client's policy is to first prefer GSSAPI mechanism X, then non-		If a client's policy is to first prefer GSSAPI mechanism X, then non-
	GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports		GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
	mechanisms Y and Z but not X, then if the client attempts to		mechanisms Y and Z but not X, then if the client attempts to
	negotiate mechanism X by using a GSS-API mechanism that negotiate		negotiate mechanism X by using a GSS-API mechanism that negotiate
	other mechanisms (such as SPNEGO), it may end up using mechanism Z		other mechanisms (such as SPNEGO), it may end up using mechanism Z
	when it ideally should have used mechanism Y. For this reason, the		when it ideally should have used mechanism Y. For this reason, the
	use of GSS-API mechanisms that negotiate other mechanisms are		use of GSS-API mechanisms that negotiate other mechanisms are
	disallowed under GS2.		disallowed under GS2.
	11.3. Resolving the problems		12.3. Resolving the problems
	GSS-API mechanisms that negotiate other mechanisms MUST NOT be used		GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
	with the GS2 SASL mechanism. This specifically exclude negotiating		with the GS2 SASL mechanism. This specifically exclude negotiating
	SPNEGO [11] under GS2.		SPNEGO [11] under GS2.
	The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [16]		The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [16]
	can be used to identify such mechanisms.		can be used to identify such mechanisms.
	12. IANA Considerations		13. IANA Considerations
	The IANA is advised that SASL mechanism names starting with "GS2-"		The IANA is advised that SASL mechanism names starting with "GS2-"
	are reserved for SASL mechanisms which conform to this document. The		are reserved for SASL mechanisms which conform to this document. The
	IANA is directed to place a statement to that effect in the sasl-		IANA is directed to place a statement to that effect in the sasl-
	mechanisms registry.		mechanisms registry.
	Subject: Registration of SASL mechanism GS2-*		Subject: Registration of SASL mechanism GS2-*
	SASL mechanism prefix: GS2-		SASL mechanism prefix: GS2-
	Security considerations: RFC [THIS-DOC]		Security considerations: RFC [THIS-DOC]
	Published specification: RFC [THIS-DOC]		Published specification: RFC [THIS-DOC]
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Simon Josefsson <[email protected]>		Simon Josefsson <[email protected]>
	Intended usage: COMMON		Intended usage: COMMON
	Owner/Change controller: [email protected]		Owner/Change controller: [email protected]
	Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.		Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
	13. Security Considerations		14. Security Considerations
	Security issues are discussed throughout this memo.		Security issues are discussed throughout this memo.
	When a server or client supports multiple authentication mechanisms,		The security provided by GS2 depends on the security provided by the
	each of which has a different security strength, it is possible for		GSS-API mechanism. If the mechanism do not provide integrity
	an active attacker to cause a party to use the least secure mechanism		protection, the authorization identity can be replaced by a man in
			the middle, and channel bindings and security layers cannot be
			negotiated. Therefor, it is generally recommended against using any
			GSS-API mechanism widely on the Internet that do not support
			integrity.
			Because the negotiation of a GSS-API mechanism may be done in the
			clear, it is important for the GSS-API mechanisms to be designed such
			that an active attacker cannot obtain an authentication with weaker
			security properties by modifying the challenges and responses.
			When a server or client supports multiple GSS-API mechanisms, each of
			which has a different security strength, it is possible for an active
			attacker to cause a party to use the least secure mechanism
	supported. There are several ways to mitigate this problem:		supported. There are several ways to mitigate this problem:
	1. Integrity protected transports can be used, e.g., TLS [14]. To		1. Integrity protected transports can be used, e.g., TLS [14]. To
	protect against certain tunnel attacks [17] with that solution, a		protect against certain tunnel attacks [17] with that solution,
	mechanism that support channel bindings that can bind the		the GSS-API mechanisms has to support integrity to provide
	security layer (e.g., the TLS session id) to the authentication		support for channel bindings
	is required.
	2. A client or server which supports mechanisms of different		2. A client or server which supports mechanisms of different
	strengths should have a configurable minimum strength that it		strengths should have a configurable minimum strength that it
	will use. It is not sufficient for this minimum strength check		will use. It is not sufficient for this minimum strength check
	to only be on the server, since an active attacker can change		to only be on the server, since an active attacker can change
	which mechanisms the client sees as being supported, causing the		which mechanisms the client sees as being supported, causing the
	client to send authentication credentials for its weakest		client to send authentication credentials for its weakest
	supported mechanism.		supported mechanism.
	Because the negotiation of a GSS-API mechanism may be done in the		3. Specify how to use the SPNEGO mechanism in SASL.
	clear, it is important for the GSS-API mechanisms to be designed such
	that an active attacker cannot obtain an authentication with weaker
	security properties by modifying the challenges and responses.
	The channel binding is sent without privacy protection and knowledge		The channel binding is sent without privacy protection and knowledge
	of it is assumed to provide no advantage to an attacker. This is a		of it is assumed to provide no advantage to an attacker. This is a
	property that has to be considered when specifying channel bindings		property that has to be considered when specifying channel bindings
	for a security protocol.		for a security protocol that will be used with GS2.
	When constructing the input_name_string, the client should not		When constructing the input_name_string, the client should not
	canonicalize the server's fully qualified domain name using an		canonicalize the server's fully qualified domain name using an
	insecure or untrusted directory service, e.g., the Domain Name System		insecure or untrusted directory service, such as the Domain Name
	[9] without DNSSEC [15].		System [9] without DNSSEC [15].
			GS2 hard code the use of the SHA-1 algorithm to compute the mechanism
			names, and it is not possible to negotiate the use of other hash
			algorithms. However, no traditional cryptographic hash properties
			(such as collision resistance or pre-image resistance) are required
			nor assumed. The required and assumed property is that it is
			statistically unlikely that two different DER-encoded OID's share the
			same first 10 octets of the SHA-1 value.
	Additional security considerations are in the SASL and GSSAPI		Additional security considerations are in the SASL and GSSAPI
	specifications. Additional security considerations for the Kerberos		specifications. Additional security considerations for the Kerberos
	V5 GSSAPI mechanism can be found in [10]. We stress that service		V5 GSSAPI mechanism can be found in [10]. We stress that service
	names should not be canonicalized using an unsecured directory		names should not be canonicalized using an unsecured directory
	service such as the DNS without DNSSEC.		service such as the DNS without DNSSEC.
	14. Acknowledgements		15. Acknowledgements
	This document is a revision of RFC 2222. This version was derived		This document is a revision of RFC 2222. This version was derived
	from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov		from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov
	with significant contributions from John G. Myers, although the		with significant contributions from John G. Myers, although the
	majority of this document has been rewritten by the current author.		majority of this document has been rewritten by the current author.
	Contributions of many members of the SASL mailing list are gratefully		Contributions of many members of the SASL mailing list are gratefully
	acknowledged. In particular, ideas and feedback from Sam Hartman,		acknowledged. In particular, ideas and feedback from Sam Hartman,
	Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu		Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu
	improved the document and the protocol.		improved the document and the protocol.
	15. References		16. References
	15.1. Normative References		16.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and		[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and
	Security Layer (SASL)", RFC 4422, June 2006.		Security Layer (SASL)", RFC 4422, June 2006.
	[3] Linn, J., "Generic Security Service Application Program		[3] Linn, J., "Generic Security Service Application Program
	Interface Version 2, Update 1", RFC 2743, January 2000.		Interface Version 2, Update 1", RFC 2743, January 2000.
	skipping to change at page 29, line 36		skipping to change at page 31, line 36
	[7] Williams, N., "On the Use of Channel Bindings to Secure		[7] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", draft-ietf-nfsv4-channel-bindings-04 (work in		Channels", draft-ietf-nfsv4-channel-bindings-04 (work in
	progress), June 2006.		progress), June 2006.
	[8] International Organization for Standardization, "Information		[8] International Organization for Standardization, "Information
	Processing Systems - Open Systems Interconnection -		Processing Systems - Open Systems Interconnection -
	Specification of Abstract Syntax Notation One (ASN.1)",		Specification of Abstract Syntax Notation One (ASN.1)",
	ISO Standard 8824, December 1990.		ISO Standard 8824, December 1990.
	15.2. Informative References		16.2. Informative References
	[9] Mockapetris, P., "Domain names - concepts and facilities",		[9] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,		[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
	June 1996.		June 1996.
	[11] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API		[11] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
	Negotiation Mechanism", RFC 2478, December 1998.		Negotiation Mechanism", RFC 2478, December 1998.
	skipping to change at page 32, line 7		skipping to change at page 34, line 7
	WWW http://www.saunalahti.fi/~asokan/research/mitm.html.		WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
	Author's Address		Author's Address
	Simon Josefsson		Simon Josefsson
	Email: [email protected]		Email: [email protected]
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2007).
	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. 65 change blocks.
	126 lines changed or deleted		198 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/