draft-ietf-sasl-gs2-03.txt		draft-ietf-sasl-gs2-04.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: April 26, 2007		Expires: June 10, 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-03		draft-ietf-sasl-gs2-04
	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 April 26, 2007.		This Internet-Draft will expire on June 10, 2007.
	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. 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
	notion of channel binding.		notion of channel binding.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 5
	3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4		3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 6
	3.2. Computing mechanism names manually . . . . . . . . . . . . 4		3.2. Computing mechanism names manually . . . . . . . . . . . . 6
	3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. SASL Authentication Exchange Message Format . . . . . . . . . 4		4. SASL Authentication Exchange Message Format . . . . . . . . . 8
	4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 4		4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 6		4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 6		4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 7		4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 8		4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11
	4.3.1. Client first GSS_Wrap input . . . . . . . . . . . . . 9		4.3.1. Client first GSS_Wrap input . . . . . . . . . . . . . 12
	4.3.2. Server last GSS_Wrap input . . . . . . . . . . . . . . 10		4.3.2. Server last GSS_Wrap input . . . . . . . . . . . . . . 13
	4.3.3. Server first GSS_Wrap input . . . . . . . . . . . . . 10		4.3.3. Server first GSS_Wrap input . . . . . . . . . . . . . 13
	4.3.4. Client last GSS_Wrap input . . . . . . . . . . . . . . 11		4.3.4. Client last GSS_Wrap input . . . . . . . . . . . . . . 14
	5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 11		5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12		6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16
	7. Authentication Conditions . . . . . . . . . . . . . . . . . . 15		7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20
	8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 15		8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21
	9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 15		9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22
	9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16		9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10. Interoperability with the GSSAPI mechanism . . . . . . . . . . 17		10. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 24
	10.1. The interoperability problem . . . . . . . . . . . . . . . 17		10.1. The interoperability problem . . . . . . . . . . . . . . . 24
	10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 17		10.2. Resolving the problem . . . . . . . . . . . . . . . . . . 24
	10.3. Additional recommendations . . . . . . . . . . . . . . . . 17		10.3. Additional recommendations . . . . . . . . . . . . . . . . 24
	11. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17		11. Mechanisms that negotiate other mechanisms . . . . . . . . . . 25
	11.1. The interoperability problem . . . . . . . . . . . . . . . 18		11.1. The interoperability problem . . . . . . . . . . . . . . . 25
	11.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18		11.2. Security problem . . . . . . . . . . . . . . . . . . . . . 25
	11.3. Resolving the problems . . . . . . . . . . . . . . . . . . 18		11.3. Resolving the problems . . . . . . . . . . . . . . . . . . 25
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 19		13. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 20		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		15.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 20		15.2. Informative References . . . . . . . . . . . . . . . . . . 29
	16.2. Informative References . . . . . . . . . . . . . . . . . . 21		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21		Intellectual Property and Copyright Statements . . . . . . . . . . 32
	Intellectual Property and Copyright Statements . . . . . . . . . . 22
	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 8		skipping to change at page 6, line 10
	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 [6] (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 [8] of the GSS-API mechanism's		computed over the ASN.1 DER encoding [8], including the tag and
	Object Identifier. The Base32 rules on padding characters and		length octets, of the GSS-API mechanism's Object Identifier. The
	characters outside of the base32 alphabet are not relevant to this		Base32 rules on padding characters and characters outside of the
	use of Base32. If any padding or non-alphabet characters are		base32 alphabet are not relevant to this use of Base32. If any
	encountered, the name is not a GS2 family mechanism name.		padding or non-alphabet characters are 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. Examples
	For example, the OID for the SPKM-1 mechanism [13] is		The OID for the SPKM-1 mechanism [13] is 1.3.6.1.5.5.1.1. The ASN.1
	1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 07 2b 06 01		DER encoding of the OID, including the tag and length, is (in hex) 06
	05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is		07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is
	1cf8f42b5a9f80fae9f831226d5d9d56278661ad. The Base32 encoding of the		(in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad.
	first ten bytes of this is "DT4PIK22T6EPV2PY". Thus the SASL		Convert the first ten octets to binary, and re-group them in groups
	mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-		of 5, and convert them back to decimal, which results in these
	DT4PIK22T6EPV2PY".		computations:
			hex:
			1c f8 f4 2b 5a 9f 80 fa e9 f8
			binary:
			00011100 11111000 11110100 00101011 01011010
			10011111 10000000 11111010 11101001 11111000
			binary in groups of 5:
			00011 10011 11100 01111 01000 01010 11010 11010
			10011 11110 00000 01111 10101 11010 01111 11000
			decimal of each group:
			3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24
			Translating each decimal value using table 3 in Base32 [6] yields the
			character sequence DT4PIK22T6APV2PY. Thus the SASL mechanism name
			for the SPKM-1 GSSAPI mechanism is "GS2-DT4PIK22T6APV2PY".
			The OID for the Kerberos V5 GSS-API mechanism [10] is
			1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
			86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
			93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
			binary, and re-group them in groups of 5, and convert them back to
			decimal, which results in these computations:
			hex:
			82 d2 73 25 76 6b d6 c8 45 aa
			binary:
			10000010 11010010 01110011 00100101 01110110
			01101011 11010110 11001000 01000101 10101010
			binary in groups of 5:
			10000 01011 01001 00111 00110 01001 01011 10110
			01101 01111 01011 01100 10000 10001 01101 01010
			decimal of each group:
			16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10
			Translating each decimal value using table 3 in Base32 [6] yields the
			character sequence QLJHGJLWNPLNQRNK. Thus the SASL mechanism name
			for the Kerberos V5 GSSAPI mechanism is "GS2-QLJHGJLWNPLNQRNK".
	4. SASL Authentication Exchange Message Format		4. SASL Authentication Exchange Message Format
	4.1. SASL Messages		4.1. SASL Messages
	During the SASL authentication exchange for GS2, a number of messages		During the SASL authentication exchange for GS2, a number of messages
	following the following format is sent between the client and server.		following the following format is sent between the client and server.
	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
	skipping to change at page 5, line 38		skipping to change at page 8, line 45
	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.		GSS_Wrap.
	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 12 octets are invalid. From that		Messages shorter than or equal to 8 octets are invalid. From that it
	it follows that not both of the "Context token length" and the "Wrap		follows that at least one of the "Context token length" and the "Wrap
	token length" integers can be zero in a particular message. If the		token length" integers MUST be non-zero in a particular message. If
	sum of the length integers is longer than the entire message size,		the sum of the length integers is longer than the entire message
	minus 8 octets for the length fields, the message is invalid.		size, minus 8 octets for the length fields, the message is invalid.
	During any successful authentication exchange, the client and server		During any successful authentication exchange, the client and server
	will each send exactly one (non-empty) "Wrap token".		will each send exactly one (non-empty) "Wrap token".
	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.
	skipping to change at page 6, line 52		skipping to change at page 10, line 10
	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.
	If the server sent a (non-empty) "Wrap token", the context token is		If the server sent a (non-empty) "Wrap token", the context token is
	processed before processing the other tokens. This is required		processed before processing the other tokens. This is required
	because GSS_Unwrap may need the context to be in the state it is		because GSS_Unwrap may need the context to be in the state it is
	after the "Context token" in the message has been processed.		after the "Context token" in the message has been processed.
	When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines		When GSS_Init_sec_context returns GSS_S_COMPLETE, the client MUST
	the context to ensure that it provides a level of protection		examine the context to ensure that it provides a level of protection
	permitted by the client's security policy.		permitted by the client's security policy.
	4.2.2. Server side		4.2.2. Server side
	The server passes the first context token to GSS_Accept_sec_context		The server passes the first context token to GSS_Accept_sec_context
	as input_token, setting input_context_handle to GSS_C_NO_CONTEXT		as input_token, setting input_context_handle to GSS_C_NO_CONTEXT
	(initially), the chan_binding set to NULL, and a suitable		(initially), the chan_binding set to NULL, and a suitable
	acceptor_cred_handle (see below).		acceptor_cred_handle (see below).
	Servers SHOULD use a credential obtained by calling GSS_Acquire_cred		Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
	skipping to change at page 8, line 13		skipping to change at page 11, line 19
	Upon successful establishment of the security context and if the		Upon successful establishment of the security context and if the
	server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor		server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
	credential handle, the server SHOULD also check using the		credential handle, the server SHOULD also check using the
	GSS_Inquire_context that the target_name used by the client matches:		GSS_Inquire_context that the target_name used by the client matches:
	- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,		- the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
	where "service" is the service name specified in the application		where "service" is the service name specified in the application
	protocol's profile, and "hostname" is the fully qualified host name		protocol's profile, and "hostname" is the fully qualified host name
	of the server.		of the server.
	When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server		When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server MUST
	examines the context to ensure that it provides a level of protection		examine the context to ensure that it provides a level of protection
	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
	skipping to change at page 9, line 48		skipping to change at page 13, line 6
	The optional field "client_cbqops" is present only if		The optional field "client_cbqops" is present only if
	"channel_binding_length" is non-zero, and indicate the client's		"channel_binding_length" is non-zero, and indicate the client's
	preferred quality of protection if channel binding negotiation		preferred quality of protection if channel binding negotiation
	succeeds. The quality of protection values are defined in section 9.		succeeds. The quality of protection values are defined in section 9.
	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 [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.2. Server last GSS_Wrap input
	The input to GSS_Wrap when the server sends a Wrap token field, after		The input to GSS_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
	skipping to change at page 17, line 18		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 GSSAPI mechanism		10. Interoperability with the SASL "GSSAPI" mechanism
	The GSSAPI mechanism [12] describe how the Kerberos V5 GSS-API		The Kerberos V5 GSS-API [10] mechanism is currently used in SASL
	mechanism [10] is used in SASL under the mechanism name "GSSAPI".		under the name "GSSAPI", see GSSAPI mechanism [12]. The Kerberos V5
	The same mechanism may also be used with the GS2 family. This causes		mechanism may also be used with the GS2 family. This causes an
	an interopability problem, which is discussed and resolved below.		interopability problem, which is discussed and resolved below.
	10.1. The 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.
	10.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
	skipping to change at page 20, line 9		skipping to change at page 28, line 14
	14. 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 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, and Nicolas Williams influenced		Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu
	the design of the document and protocol.		improved the document and the protocol.
	15. Copying Conditions
	Copyright (C) 2005, 2006 Simon Josefsson
	Regarding the portion of this document that was written by Simon
	Josefsson ("the author", for the remainder of this section), the
	author makes no guarantees and is not responsible for any damage
	resulting from its use. The author grants irrevocable permission to
	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,
	provided that redistributed derivative works do not contain
	misleading author or version information. Derivative works need not
	be licensed under similar terms. Contact the author to confirm which
	sections are available under this license.
	16. References		15. References
	16.1. Normative References		15.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.
	[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] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
	draft-josefsson-rfc3548bis-04 (work in progress), May 2006.
	[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
	STD 63, RFC 3629, November 2003.		STD 63, RFC 3629, November 2003.
			[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
			RFC 4648, October 2006.
	[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.
	16.2. Informative References		15.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.
	[12] Melnikov, A., "SASL GSSAPI mechanisms",		[12] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication
	draft-ietf-sasl-gssapi-03 (work in progress), September 2005.		and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
	[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",		[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
	RFC 2025, October 1996.		RFC 2025, October 1996.
	[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)		[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
	Protocol Version 1.1", RFC 4346, April 2006.		Protocol Version 1.1", RFC 4346, April 2006.
	[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"DNS Security Introduction and Requirements", RFC 4033,		"DNS Security Introduction and Requirements", RFC 4033,
	March 2005.		March 2005.
End of changes. 21 change blocks.
	97 lines changed or deleted		125 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/