draft-ietf-sasl-gs2-00.txt		draft-ietf-sasl-gs2-01.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Expires: August 17, 2006		Expires: December 28, 2006
	Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family		Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	draft-ietf-sasl-gs2-00		draft-ietf-sasl-gs2-01
	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 33		skipping to change at page 1, line 33
	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 August 17, 2006.		This Internet-Draft will expire on December 28, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	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.		Authentication and Security Layer (SASL) framework.
	See <http://josefsson.org/sasl-gs2-*/> for more information.		See <http://josefsson.org/sasl-gs2-*/> for more information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in this Document . . . . . . . . . . . . . . 3		2. Conventions Used in this Document . . . . . . . . . . . . . . 3
	3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 3		3.1. Generating SASL Mechanism Names From GSS-API OIDs . . . . 3
	3.2. Computing mechanism names manually . . . . . . . . . . . . 4		3.2. Computing Mechanism Names Manually . . . . . . . . . . . . 4
	3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. SASL tokens . . . . . . . . . . . . . . . . . . . . . . . 4		4.1. SASL Tokens . . . . . . . . . . . . . . . . . . . . . . . 4
	4.2. Context token . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.3. Wrap token . . . . . . . . . . . . . . . . . . . . . . . . 6		4.3. Context Token . . . . . . . . . . . . . . . . . . . . . . 6
	4.3.1. Wrap token input for client requests . . . . . . . . . 7		4.4. Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3.2. Wrap token input for server responses . . . . . . . . 8		4.4.1. Wrap Token Input For Client Requests . . . . . . . . . 7
	4.3.3. Wrap token input for server requests . . . . . . . . . 8		4.4.2. WraP Token Input For Server Responses . . . . . . . . 8
	4.3.4. Wrap token input for client responses . . . . . . . . 9		4.4.3. Wrap Token Input For Server Requests . . . . . . . . . 9
	5. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 9		4.4.4. Wrap Token Input For Client Responses . . . . . . . . 9
	6. Authentication Conditions . . . . . . . . . . . . . . . . . . 12		5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10
	7. GSS-API parameters . . . . . . . . . . . . . . . . . . . . . . 12		5.1. Name Of Tls Channel For Use As Channel Binding . . . . . . 11
	8. Security layer bits . . . . . . . . . . . . . . . . . . . . . 13		6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
	9. Interoperability with the GSSAPI mechanism . . . . . . . . . . 13		7. Authentication Conditions . . . . . . . . . . . . . . . . . . 14
	9.1. Interoperability problem . . . . . . . . . . . . . . . . . 13		8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 14
	9.2. Resolving the problem . . . . . . . . . . . . . . . . . . 13		9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 15
	9.3. Additional recommendations . . . . . . . . . . . . . . . . 13		10. Interoperability With The Gssapi Mechanism . . . . . . . . . . 15
	10. Mechanisms that negotiate other mechanisms . . . . . . . . . . 14		10.1. The Interoperability problem . . . . . . . . . . . . . . . 15
	10.1. Interoperability problem . . . . . . . . . . . . . . . . . 14		10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 15
	10.2. Security problem . . . . . . . . . . . . . . . . . . . . . 14		10.3. Additional recommendations . . . . . . . . . . . . . . . . 15
	10.3. Resolving the problems . . . . . . . . . . . . . . . . . . 14		11. Mechanisms That Negotiate Other Mechanisms . . . . . . . . . . 16
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		11.1. The Interoperability Problem . . . . . . . . . . . . . . . 16
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 15		11.2. Security Problem . . . . . . . . . . . . . . . . . . . . . 16
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		11.3. Resolving the Problems . . . . . . . . . . . . . . . . . . 16
	14. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 16		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 16		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	15.2. Informative References . . . . . . . . . . . . . . . . . . 17		15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 18
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		16.1. Normative References . . . . . . . . . . . . . . . . . . . 18
			16.2. Informative References . . . . . . . . . . . . . . . . . . 19
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
			Intellectual Property and Copyright Statements . . . . . . . . . . 21
	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 3, line 48		skipping to change at page 3, line 48
	mechanism.		mechanism.
	2. Conventions Used in this Document		2. Conventions Used in this Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [1].		document are to be interpreted as described in [1].
	3. Mechanism Name		3. Mechanism Name
	3.1. Generating SASL mechanism names from GSS-API OIDs		3.1. Generating SASL Mechanism Names From GSS-API OIDs
	The SASL mechanism name for a GSS-API mechanism is the concatenation		The SASL mechanism name for a GSS-API mechanism is the concatenation
	of the string "GS2-" and the Base32 encoding [5] (with an upper case		of the string "GS2-" and the Base32 encoding [5] (with an upper case
	alphabet) of the first ten bytes of the binary SHA-1 hash [4] string		alphabet) of the first ten bytes of the binary SHA-1 hash [4] string
	computed over the ASN.1 DER encoding [7] of the GSS-API mechanism's		computed over the ASN.1 DER encoding [7] of the GSS-API mechanism's
	Object Identifier. The Base32 rules on padding characters and		Object Identifier. The Base32 rules on padding characters and
	characters outside of the base32 alphabet are not relevant to this		characters outside of the base32 alphabet are not relevant to this
	use of Base32. If any padding or non-alphabet characters are		use of Base32. If any padding or non-alphabet characters are
	encountered, the name is not a GS2 family mechanism name.		encountered, the name is not a GS2 family mechanism name.
	3.2. Computing mechanism names manually		3.2. Computing Mechanism Names Manually
	The SASL mechanism name may be computed manually. This is useful		The SASL mechanism name may be computed manually. This is useful
	when the set of supported GSS-API mechanisms is known in advance. It		when the set of supported GSS-API mechanisms is known in advance. It
	also obliterate the need to implement Base32, SHA-1 and DER in the		also obliterate the need to implement Base32, SHA-1 and DER in the
	SASL mechanism. The computed mechanism name can be used directly in		SASL mechanism. The computed mechanism name can be used directly in
	the implementation, and the implementation need not concern itself		the implementation, and the implementation need not concern itself
	with that the mechanism is part of a mechanism family.		with that the mechanism is part of a mechanism family.
	3.3. Example		3.3. Example
	For example, the OID for the SPKM-1 mechanism [12] is		For example, the OID for the SPKM-1 mechanism [12] is
	1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 07 2b 06 01		1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 07 2b 06 01
	05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is		05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is
	1cf8f42b5a9f80fae9f831226d5d9d56278661ad. The Base32 encoding of the		1cf8f42b5a9f80fae9f831226d5d9d56278661ad. The Base32 encoding of the
	first ten bytes of this is "dt4pik22t6epv2py". Thus the SASL		first ten bytes of this is "dt4pik22t6epv2py". Thus the SASL
	mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-		mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-
	DT4PIK22T6EPV2PY".		DT4PIK22T6EPV2PY".
	4. Packet format		4. Packet Format
	4.1. SASL tokens		4.1. SASL Tokens
	All top-level SASL packets for the GS2 mechanism family follow the		All top-level SASL packets for the GS2 mechanism family follow the
	following format:		following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Context length |		| Context length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Flags |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| /		| /
	/ Context token /		/ Context token /
	/ --------------------/		/ --------------------/
	/ ---------------------/ /		/ ---------------------/ /
	/--------------------/ /		/--------------------/ /
	/ [Wrap token] /		/ [Wrap token] /
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The "Context length" field is a 4 octet (32 bit) integer encoded in		The "Context length" field is a 4 octet (32 bit) integer encoded in
	network byte order, it indicate the length of the "Context token"		network byte order, it indicate the length of the "Context token"
	field.		field.
			The "Flags" field is a 4 octet (32 bit) bitmask that holds flags that
			influence the authentication process.
	The "Context token" field contain a GSS-API context establishment		The "Context token" field contain a GSS-API context establishment
	token generated by GSS_Init_sec_context or GSS_Accept_sec_context.		token generated by GSS_Init_sec_context or GSS_Accept_sec_context.
	The "Wrap token" field is optional, and if present will contain the		The "Wrap token" field is optional, and if present will contain the
	output generated by GSS_Wrap.		output generated by GSS_Wrap.
	The length field does not include the length of the length field		The length field does not include the length of the length field
	itself. Whether the "Wrap token" field is included or not can be		itself. Whether the "Wrap token" field is included or not can be
	infered from the length field; if the length field is shorter than		infered from the length field; if the length field is shorter than
	the entire packet size minus 4 octets, the "Wrap token" field is		the entire packet size minus 4 octets, the "Wrap token" field is
	present and begins after length+4 octets into the packet. The tokens		present and begins after length+4 octets into the packet. The tokens
	need not be aligned to 32-bit a boundary. There is no padding		need not be aligned to 32-bit a boundary. There is no padding
	between the tokens.		between the tokens.
	Packets shorter than 4 octets are invalid. If the length field is		Packets shorter than 4 octets are invalid. If the length field is
	longer than the entire packet size, minus 4 octets, the packet is		longer than the entire packet size, minus 4 octets, the packet is
	invalid.		invalid.
	4.2. Context token		4.2. Flags
			Bit 0 signal whether GSS-API Channel bindings are used. It is only
			useful in the first token sent from the client, and MUST be set to 0
			in all other tokens. The bit is called the "Native Channel Bindings"
			bit. The client chooses whether to set this bit or not depending on
			local policy or user requests.
			The other bits are not specified and MUST be zero. If a bit is set
			that is not understood by the implementation, it MUST be ignored.
			4.3. Context Token
	The format of the "Context token" field inside the SASL token are		The format of the "Context token" field inside the SASL token are
	defined by the GSS-API specifications, see GSS_Init_sec_context and		defined by the GSS-API specifications, and the data is computed by
	GSS_Accept_sec_context.		the GSS_Init_sec_context and GSS_Accept_sec_context functions.
	The client calls GSS_Init_sec_context, passing in		The client calls GSS_Init_sec_context, passing in
	input_context_handle of 0 (initially), mech_type of the GSSAPI		input_context_handle of 0 (initially), mech_type of the GSSAPI
	mechanism for which this SASL mechanism is registered, any		mechanism for which this SASL mechanism is registered, the
	chan_binding if requested by the application (XXX?), and targ_name		chan_binding is set to NULL or the channel binding data depending on
	equal to output_name from GSS_Import_Name called with input_name_type		the Native Channel Binding flag, and targ_name equal to output_name
	of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of		from GSS_Import_Name called with input_name_type 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. If the client will be requesting a security		name of the server. If the client will be requesting a security
	layer, it MUST also supply to the GSS_Init_sec_context a		layer, it MUST also supply to the GSS_Init_sec_context a
	mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an		mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
	integ_req_flag of TRUE. If the client will be requesting a security		integ_req_flag of TRUE. If the client will be requesting a security
	layer providing confidentiality protection, it MUST also supply to		layer providing confidentiality protection, it MUST also supply to
	the GSS_Init_sec_context a conf_req_flag of TRUE. If		the GSS_Init_sec_context a conf_req_flag of TRUE. If
	GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client		GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
	should expect the server to issue a token in a subsequent challenge		should expect the server to issue a token in a subsequent challenge
	skipping to change at page 6, line 13		skipping to change at page 6, line 44
	GSS_S_COMPLETE is returned or authentication is aborted. If the		GSS_S_COMPLETE is returned or authentication is aborted. If the
	server supply data beyond the context token, the context token should		server supply data beyond the context token, the context token should
	be processed first, and then the overflow data should be passed to		be processed first, and then the overflow data should be passed to
	GSS_Unwrap and the unwrapped data should be interpreted. During the		GSS_Unwrap and the unwrapped data should be interpreted. During the
	authentication exchange, the client will generate one Wrap token		authentication exchange, the client will generate one Wrap token
	using GSS_Wrap.		using GSS_Wrap.
	The server passes the first client response to GSS_Accept_sec_context		The server passes the first client response to GSS_Accept_sec_context
	as input_token, setting input_context_handle to 0 (initially),		as input_token, setting input_context_handle to 0 (initially),
	mech_type of the GSSAPI mechanism for which this SASL mechanism is		mech_type of the GSSAPI mechanism for which this SASL mechanism is
	registered, any chan_binding if requested by the application (XXX?),		registered, the chan_binding set to NULL or the channel binding data
	and acceptor_cred_handle equal to output_cred_handle from		depending on the Native Channel Binding bit, and acceptor_cred_handle
	GSS_Acquire_cred called with desired_name equal to output_name from		equal to output_cred_handle from GSS_Acquire_cred called with
	GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE		desired_name equal to output_name from GSS_Import_name with
	and input_name_string of "service@hostname" where "service" is the		input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string
	service name specified in the protocol's profile, and "hostname" is		of "service@hostname" where "service" is the service name specified
	the fully qualified host name of the server. The server must pass		in the protocol's profile, and "hostname" is the fully qualified host
	any resulting challenge from the client to another call to		name of the server. The server must pass any resulting challenge
	GSS_Accept_sec_context, repeating the actions in this paragraph,		from the client to another call to GSS_Accept_sec_context, repeating
	until GSS_S_COMPLETE is returned or authentication is aborted. If		the actions in this paragraph, until GSS_S_COMPLETE is returned or
	the client supply data beyond the context token, the context token		authentication is aborted. If the client supply data beyond the
	should be processed first, and then the overflow data should be		context token, the context token should be processed first, and then
	passed to GSS_Unwrap and the unwrapped data should be interpreted.		the overflow data should be passed to GSS_Unwrap and the unwrapped
	During the authentication exchange, the server will generate one Wrap		data should be interpreted. During the authentication exchange, the
	token using GSS_Wrap.		server will generate one Wrap token using GSS_Wrap.
	4.3. Wrap token		4.4. Wrap Token
	The Wrap token MUST NOT be sent before the PROT_READY flag has been		The Wrap token MUST NOT be sent before the PROT_READY flag has been
	set locally (by GSS_Init_sec_context or Gss_Accept_sec_context), or		set locally (by GSS_Init_sec_context or Gss_Accept_sec_context), or
	if the PROT_READY flag is never set, before the context has been		if the PROT_READY flag is never set, before the context has been
	fully established. The GSS_Wrap token does not have to be sent		fully established. The GSS_Wrap token does not have to be sent
	directly when the PROT_READY flag is set. During any exchange,		directly when the PROT_READY flag is set. During any exchange,
	exactly one GSS_Wrap token is sent in each direction. The input to		exactly one GSS_Wrap token is sent in each direction. The input to
	the GSS_Wrap function MUST follow the format described below. If not		the GSS_Wrap function MUST follow the format described below. If not
	exactly one GSS_Wrap token is received by the client and by the		exactly one GSS_Wrap token is received by the client and by the
	server, the authentication MUST fail.		server, the authentication MUST fail.
	skipping to change at page 7, line 18		skipping to change at page 7, line 47
	when the server sends the GSS_Wrap token first and the client		when the server sends the GSS_Wrap token first and the client
	responds.		responds.
	The input formats below are passed to GSS_Wrap with conf_flag set to		The input formats below are passed to GSS_Wrap with conf_flag set to
	FALSE, and the Wrap token output will be the generated		FALSE, and the Wrap token output will be the generated
	output_message.		output_message.
	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. Wrap token input for client requests		4.4.1. Wrap Token Input For Client Requests
	The input to GSS_Wrap when the client sends the GSS_Wrap token first		The input to GSS_Wrap when the client sends the GSS_Wrap token 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 |
	skipping to change at page 8, line 10		skipping to change at page 8, line 41
	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 [6]. The authorization		authorization identity is encoded using UTF-8 [6]. 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. Wrap token input for server responses		4.4.2. WraP Token Input For Server Responses
	The data format for input to GSS_Wrap when the server responds to the		The data format for input to GSS_Wrap when the server responds to the
	previous GSS_Wrap token data is as follows.		previous GSS_Wrap token data 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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
	protection.		protection.
	The "server_maxbuf" field indicate the maximum data buffer size the		The "server_maxbuf" field indicate the maximum data buffer size the
	server can receive. It MUST be 0 if the server doesn't advertise		server can receive. It MUST be 0 if the server doesn't advertise
	support for any security layer, the client MUST verify this.		support for any security layer, the client MUST verify this.
	4.3.3. Wrap token input for server requests		4.4.3. Wrap Token Input For Server Requests
	The data format for input to GSS_Wrap when the server sends the		The data format for input to GSS_Wrap when the server sends the
	GSS_Wrap token first is as follows.		GSS_Wrap token first 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| server_qops | server_maxbuf |		| server_qops | server_maxbuf |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| channel_binding_length |		| channel_binding_length |
	skipping to change at page 9, line 12		skipping to change at page 9, line 43
	The optional field "server_cbqops" is present only if		The optional field "server_cbqops" is present only if
	"channel_binding_length" is non-zero, and indicate the server's		"channel_binding_length" is non-zero, and indicate the server's
	preferred quality of protection if channel binding negotiation		preferred quality of protection if channel binding negotiation
	succeeds.		succeeds.
	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.
	4.3.4. Wrap token input for client responses		4.4.4. Wrap Token Input For Client Responses
	The data format for input to GSS_Wrap when the client responds to the		The data format for input to GSS_Wrap when the client responds to the
	previous token is as follows.		previous token 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] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The "client_qop" field is the selected quality of protection.		The "client_qop" field is the selected quality of protection.
	The "client_maxbuf" and "authzid" fields are as above.		The "client_maxbuf" and "authzid" fields are as above.
	5. Protocol overview		5. Channel Bindings
			[[This section is tentative further discussion on the topic. This
			was written to provide an example of how the details of how one
			approach to this concept could look like. There are other approaches
			that may be preferable.]]
			The GS2 mechanism provide its own token field for channel bindings,
			in addition to the "chan_binding" parameter in the GSS-API context
			functions. The reason for this is that the GS2 mechanism wish to
			provide an option to proceed even if the channel bindings does not
			match. The GSS-API framework specifies that authentication cannot
			proceed if channel bindings does not match. The GSS-API framework
			also does not specify the kind of privacy layer the channel binding
			should be transferred under, thus making it possible for attackers to
			modify it to always make channel binding negotiation succeed.
			The client can select, using the "Native Channel Bindings" bit,
			whether it wishes to use the "chan_bindings" parameter in the GSS-API
			layer or not. If it wishes to use this, it is not possible to
			continue after a failed channel binding negotiation.
			A client that wish to continue with the authentication even if the
			channel bindings does not match, set the "Native Channel Binding" bit
			to 0. It MUST use the channel binding field in the GS2 token. It
			MUST set the "chan_binding" parameter in the calls to
			GSS_Init_sec_context to GSS_Accept_sec_context to NULL. The
			application MUST set the "client_qops" field to include privacy
			protection (to protect the SASL application data), and MAY set the
			"client_cbqops" to no security layer (to avoid performance
			degradation due to two security layers).
			If a client do not wish to continue the authentication if channel
			binding negotiation fails, or wishes to use the channel binding in
			the GSS-API layer, it will set the "Native Channel Binding" bit to 1
			in its first token. It MUST use both the channel binding field in
			the GS2 token and the "chan_binding" parameter in the calls to
			GSS_Init_sec_context and GSS_Accept_sec_context. The authentication
			will fail in the GSS-API layer if the channel bindings does not
			match, and thus the "client_qops" and "client_cbqops" MUST be set to
			the same value. It MAY be set to no security layer (to avoid
			performance degradation due to two security layers).
			For TLS, the channel binding data is specified in the next section.
			For other security layers, channel binding data will have to
			specified elsewhere, and this specification will have to be updated
			with explicit considerations.
			[[All channel bindings should go into a separate document.]]
			5.1. Name Of Tls Channel For Use As Channel Binding
			The TLS Pseudo-Random Function (PRF) generate, using the constant
			string "TLS channel binding", and based on the master secret and the
			random values established during a TLS handshake, a 64 octet string
			that make up the SASL channel binding data.
			Using the terminology of TLS [13], the channel binding data is
			computed as follows:
			SASL_channel_binding =
			PRF(SecurityParameters.master_secret,
			"TLS channel binding",
			SecurityParameters.server_random +
			SecurityParameters.client_random) [0..64];
			The derived data is intended to be used as a name of the TLS channel
			that is cryptographically bound to the channel, for use in
			authentication mechanisms tunneled over TLS.
			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 authentication exchange using GS2 may look like:		An authentication exchange using GS2 may look like:
	skipping to change at page 12, line 24		skipping to change at page 14, line 24
	GSS_Wrap (client_qops, client_maxbuf,		GSS_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 [length, GSS_Accept_sec_context,
	GSS_Wrap(server_qop, server_maxbuf)] token		GSS_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.
	6. 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:
	o An invalid SASL token is received (i.e., length shorter than 4		o An invalid SASL token is received (i.e., length shorter than 4
	octets).		octets).
	o GSS_Init/Accept_sec_context() return anything other than		o GSS_Init/Accept_sec_context() return anything other than
	GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.		GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
	o GSS_Wrap() returns anything other than GSS_S_COMPLETE.		o GSS_Wrap() returns anything other than GSS_S_COMPLETE.
	o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There		o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There
	can't be supplementary status codes in GS2 at this point, so any		can't be supplementary status codes in GS2 at this point, so any
	indications of out of order processing or replays should be		indications of out of order processing or replays should be
	fatal.)		fatal.)
	o The token returned from GSS_Unwrap fail to parse correctly (e.g.,		o The token returned from GSS_Unwrap fail to parse correctly (e.g.,
	too short, invalid maximum buffer size) as the expected Wrap		too short, invalid maximum buffer size) as the expected Wrap
	token.		token.
	o Local policy reject the attempt. For example, client and server		o Local policy reject the attempt. For example, client and server
	can't agree on qop proposal.		can't agree on qop proposal.
	o (server-side) Authorization of client principal (i.e., src_name in		o (server-side) Authorization of client principal (i.e., src_name in
	GSS_Acecpt_sec_context) to requested authzid failed.		GSS_Acecpt_sec_context) to requested authzid failed.
	7. GSS-API parameters		8. GSS-API Parameters
	The implementation MAY set any GSSAPI flags or arguments not		The implementation MAY set any GSSAPI flags or arguments not
	mentioned in this specification as is necessary for the		mentioned in this specification as is necessary for the
	implementation to enforce its security policy.		implementation to enforce its security policy.
	8. Security layer bits		9. Security Layer Bits
	The security layers and their corresponding bit-masks are as follows:		The security layers and their corresponding bit-masks are as follows:
	1 No security layer		1 No security layer
	2 Integrity protection.		2 Integrity protection.
	Sender calls GSS_Wrap with conf_flag set to FALSE		Sender calls GSS_Wrap with conf_flag set to FALSE
	4 Confidentiality protection.		4 Confidentiality protection.
	Sender calls GSS_Wrap with conf_flag set to TRUE		Sender calls GSS_Wrap with conf_flag set to TRUE
	Other bit-masks may be defined in the future; bits which are not		Other bit-masks may be defined in the future; bits which are not
	understood must be negotiated off.		understood must be negotiated off.
	Note that SASL negotiates the maximum size of the output_message to		Note that SASL negotiates the maximum size of the output_message to
	send. Implementations can use the GSS_Wrap_size_limit call to		send. Implementations can use the GSS_Wrap_size_limit call to
	determine the corresponding maximum size input_message.		determine the corresponding maximum size input_message.
	9. Interoperability with the GSSAPI mechanism		10. Interoperability With The Gssapi Mechanism
	The GSSAPI mechanism [11] describe how the Kerberos V5 GSS-API		The GSSAPI mechanism [11] describe how the Kerberos V5 GSS-API
	mechanism [9] is used in SASL under the mechanism name "GSSAPI". The		mechanism [9] is used in SASL under the mechanism name "GSSAPI". The
	same mechanism may also be used with the GS2 family. This causes an		same 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.
	9.1. Interoperability problem		10.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.
	9.2. Resolving the problem		10.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 [16].		could enable certain tunnel attacks [16].
	9.3. Additional recommendations		10.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.
	10. Mechanisms that negotiate other mechanisms		11. 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.
	10.1. Interoperability problem		11.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.
	10.2. Security problem		11.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 should have used mechanism Y. For this reason, the use of		when it should have used mechanism Y. For this reason, the use of
	GSS-API mechanisms that negotiate other mechanisms are disallowed		GSS-API mechanisms that negotiate other mechanisms are disallowed
	under GS2.		under GS2.
	10.3. Resolving the problems		11.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 [10] under GS2.		SPNEGO [10] under GS2.
	The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [15]		The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [15]
	can be used to identify such mechanisms.		can be used to identify such mechanisms.
	11. IANA Considerations		12. 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-*
	Family of SASL mechanisms: YES		Family of SASL mechanisms: YES
	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 <simon@josefsson.org>		Simon Josefsson <simon@josefsson.org>
	Intended usage: COMMON		Intended usage: COMMON
	Owner/Change controller: iesg@ietf.org		Owner/Change controller: iesg@ietf.org
	Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.		Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
	12. Security Considerations		13. 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,		When a server or client supports multiple authentication mechanisms,
	each of which has a different security strength, it is possible for		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		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 [13]. To		1. Integrity protected transports can be used, e.g., TLS [13]. To
	protect against certain tunnel attacks [16] with that solution, a		protect against certain tunnel attacks [16] with that solution, a
	skipping to change at page 16, line 12		skipping to change at page 18, line 12
	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, e.g., the Domain Name System
	[8] without DNSSEC [14].		[8] without DNSSEC [14].
	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 [9]. We stress that service		V5 GSSAPI mechanism can be found in [9]. 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.
	13. Acknowledgements		14. 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 this		with significant contributions from John G. Myers, although this
	document has been rewritten by the current author.		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 from Sam Hartman, Jeffrey		acknowledged. In particular, ideas from Sam Hartman, Jeffrey
	Hutzelman, and Nicolas Williams influenced the design of this		Hutzelman, and Nicolas Williams influenced the design of this
	protocol.		protocol.
	14. Copying conditions		15. Copying Conditions
	Regarding the portion of this document that was written by Simon		Regarding the portion of this document that was written by Simon
	Josefsson ("the author", for the remainder of this section), the		Josefsson ("the author", for the remainder of this section), the
	author makes no guarantees and is not responsible for any damage		author makes no guarantees and is not responsible for any damage
	resulting from its use. The author grants irrevocable permission to		resulting from its use. The author grants irrevocable permission to
	anyone to use, modify, and distribute it in any way that does not		anyone to use, modify, and distribute it in any way that does not
	diminish the rights of anyone else to use, modify, and distribute it,		diminish the rights of anyone else to use, modify, and distribute it,
	provided that redistributed derivative works do not contain		provided that redistributed derivative works do not contain
	misleading author or version information. Derivative works need not		misleading author or version information. Derivative works need not
	be licensed under similar terms. Contact the author to confirm which		be licensed under similar terms. Contact the author to confirm which
	sections are available under this license.		sections are available under this license.
	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] Myers, J., "Simple Authentication and Security Layer (SASL)",		[2] Myers, J., "Simple Authentication and Security Layer (SASL)",
	RFC 2222, October 1997.		RFC 2222, October 1997.
	[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.
	[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",		[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
	RFC 3174, September 2001.		RFC 3174, September 2001.
	[5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",		[5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
	draft-josefsson-rfc3548bis-00 (work in progress), November 2005.		draft-josefsson-rfc3548bis-04 (work in progress), May 2006.
	[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",		[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
	STD 63, RFC 3629, November 2003.		STD 63, RFC 3629, November 2003.
	[7] "Information Processing Systems - Open Systems Interconnection -		[7] "Information Processing Systems - Open Systems Interconnection -
	Specification of Abstract Syntax Notation One (ASN.1)", ISO		Specification of Abstract Syntax Notation One (ASN.1)", ISO
	Standard 8824.		Standard 8824.
	15.2. Informative References		16.2. Informative References
	[8] Mockapetris, P., "Domain names - concepts and facilities",		[8] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[9] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,		[9] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
	June 1996.		June 1996.
	[10] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API		[10] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
	Negotiation Mechanism", RFC 2478, December 1998.		Negotiation Mechanism", RFC 2478, December 1998.
End of changes. 41 change blocks.
	85 lines changed or deleted		176 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/