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.