draft-ietf-sasl-gs2-09.txt		draft-ietf-sasl-gs2-10.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Intended status: Standards Track		Intended status: Standards Track
	Expires: April 11, 2008		Expires: January 14, 2009
	Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family		Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	draft-ietf-sasl-gs2-09		draft-ietf-sasl-gs2-10
	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 11, 2008.		This Internet-Draft will expire on January 14, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (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 29		skipping to change at page 3, line 29
	4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12		4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12
	4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12		4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12
	4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13		4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13
	4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14		4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14
	4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14		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 . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24		10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24
	11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25		11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25
	11.1. The interoperability problem . . . . . . . . . . . . . . . 25		11.1. The interoperability problem . . . . . . . . . . . . . . . 25
	11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25		11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25
	11.3. Additional recommendations . . . . . . . . . . . . . . . . 25		11.3. Additional recommendations . . . . . . . . . . . . . . . . 25
	12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26		12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26
	12.1. The interoperability problem . . . . . . . . . . . . . . . 26		12.1. The interoperability problem . . . . . . . . . . . . . . . 26
	12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26		12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26
	12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26		12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 28		14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 31		16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
	16.2. Informative References . . . . . . . . . . . . . . . . . . 31		16.2. Informative References . . . . . . . . . . . . . . . . . . 31
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . . . . 34		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)
	is a framework that provide security services to applications.		[RFC2743] is a framework that provide security services to
	Simple Authentication and Security Layer (SASL) [2] is a framework to		applications. Simple Authentication and Security Layer (SASL)
	provide authentication and security layers for connection based		[RFC4422] is a framework to provide authentication and security
	protocols. This document describe how to use a GSS-API mechanism in		layers for connection based protocols. This document describe how to
	a connection-based protocol using the SASL framework.		use a GSS-API mechanism in a connection-based protocol using the SASL
			framework.
	All GSSAPI mechanisms are implicitly registered for use within SASL		All GSSAPI mechanisms are implicitly registered for use within SASL
	by this specification. The SASL mechanism defined in this document		by this specification. The SASL mechanism defined in this document
	is known as the GS2 family.		is known as the GS2 family.
	The "Kerberos V5 GSS-API mechanism" [10] is also supported in SASL		The "Kerberos V5 GSS-API mechanism" [RFC1964] is also supported in
	through "SASL GSSAPI mechanisms" [12]. The difference between that		SASL through "SASL GSSAPI mechanisms" [RFC4752]. The difference
	protocol and the one described here, is that this protocol offer more		between that protocol and the one described here, is that this
	features (i.e., channel bindings and round-trip optimizations) while		protocol offer more features (i.e., channel bindings and round-trip
	the other protocol is more widely deployed. There are		optimizations) while the other protocol is more widely deployed.
	interoperability concerns by having the same GSS-API mechanism		There are interoperability concerns by having the same GSS-API
	available under more than one SASL mechanism name, see the section		mechanism available under more than one SASL mechanism name, see the
	"Interoperability with the GSSAPI mechanism" below.		section "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 [RFC4178]), see the section
	"Mechanisms that negotiate other mechanisms" below.		"Mechanisms that negotiate other mechanisms" below.
	There are interoperability and security concerns with GSSAPI		There are interoperability and security concerns with GSSAPI
	mechanism that do not provide integrity, see the section "Non-		mechanism that do not provide integrity, see the section "Non-
	integrity capable GSS-API mechanisms" below.		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
	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 [RFC2119].
	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 [6] (with an upper case		of the string "GS2-" and the Base32 encoding [RFC4648] (with an upper
	alphabet) of the first ten bytes of the binary SHA-1 hash [4] string		case alphabet) of the first ten bytes of the binary SHA-1 hash
	computed over the ASN.1 DER encoding [7], including the tag and		[FIPS.180-1.1995] string computed over the ASN.1 DER encoding
	length octets, of the GSS-API mechanism's Object Identifier. The		[ITU.X690.1994], including the tag and length octets, of the GSS-API
	Base32 rules on padding characters and characters outside of the		mechanism's Object Identifier. The Base32 rules on padding
	base32 alphabet are not relevant to this use of Base32. If any		characters and characters outside of the base32 alphabet are not
	padding or non-alphabet characters are encountered, the name is not a		relevant to this use of Base32. If any padding or non-alphabet
	GS2 family mechanism name.		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. Examples		3.3. Examples
	The OID for the SPKM-1 mechanism [13] is 1.3.6.1.5.5.1.1. The ASN.1		The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The
	DER encoding of the OID, including the tag and length, is (in hex) 06		ASN.1 DER encoding of the OID, including the tag and length, is (in
	07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is		hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER
	(in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad.		encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56
	Convert the first ten octets to binary, and re-group them in groups		27 86 61 ad. Convert the first ten octets to binary, and re-group
	of 5, and convert them back to decimal, which results in these		them in groups of 5, and convert them back to decimal, which results
	computations:		in these computations:
	hex:		hex:
	1c f8 f4 2b 5a 9f 80 fa e9 f8		1c f8 f4 2b 5a 9f 80 fa e9 f8
	binary:		binary:
	00011100 11111000 11110100 00101011 01011010		00011100 11111000 11110100 00101011 01011010
	10011111 10000000 11111010 11101001 11111000		10011111 10000000 11111010 11101001 11111000
	binary in groups of 5:		binary in groups of 5:
	00011 10011 11100 01111 01000 01010 11010 11010		00011 10011 11100 01111 01000 01010 11010 11010
	skipping to change at page 7, line 4		skipping to change at page 7, line 20
	10011111 10000000 11111010 11101001 11111000		10011111 10000000 11111010 11101001 11111000
	binary in groups of 5:		binary in groups of 5:
	00011 10011 11100 01111 01000 01010 11010 11010		00011 10011 11100 01111 01000 01010 11010 11010
	10011 11110 00000 01111 10101 11010 01111 11000		10011 11110 00000 01111 10101 11010 01111 11000
	decimal of each group:		decimal of each group:
	3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24		3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24
	base32 encoding:		base32 encoding:
	D T 4 P I K 2 2 T 6 A P V 2 P Y		D T 4 P I K 2 2 T 6 A P V 2 P Y
	The last step translate each decimal value using table 3 in Base32		The last step translate each decimal value using table 3 in Base32
	[6]. Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is		[RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI
	"GS2-DT4PIK22T6APV2PY".		mechanism is "GS2-DT4PIK22T6APV2PY".
	The OID for the Kerberos V5 GSS-API mechanism [10] is		The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
	1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48		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		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		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		binary, and re-group them in groups of 5, and convert them back to
	decimal, which results in these computations:		decimal, which results in these computations:
	hex:		hex:
	82 d2 73 25 76 6b d6 c8 45 aa		82 d2 73 25 76 6b d6 c8 45 aa
	binary:		binary:
	skipping to change at page 7, line 36		skipping to change at page 7, line 51
	10000 01011 01001 00111 00110 01001 01011 10110		10000 01011 01001 00111 00110 01001 01011 10110
	01101 01111 01011 01100 10000 10001 01101 01010		01101 01111 01011 01100 10000 10001 01101 01010
	decimal of each group:		decimal of each group:
	16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10		16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10
	base32 encoding:		base32 encoding:
	Q L J H G J L W N P L M Q R N K		Q L J H G J L W N P L M Q R N K
	The last step translate each decimal value using table 3 in Base32		The last step translate each decimal value using table 3 in Base32
	[6]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI		[RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI
	mechanism is "GS2-QLJHGJLWNPLMQRNK".		mechanism is "GS2-QLJHGJLWNPLMQRNK".
	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
	skipping to change at page 13, line 23		skipping to change at page 13, line 23
	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 [5]. The authorization		authorization identity is encoded using UTF-8 [RFC3629]. The
	identity is not terminated with the NUL (U+0000) character. Servers		authorization identity is not terminated with the NUL (U+0000)
	MUST validate that the authorization identity is valid UTF-8.		character. Servers MUST validate that the authorization identity is
			valid UTF-8.
	4.3.3. Server last GS2_Wrap input		4.3.3. Server last GS2_Wrap input
	The input to GS2_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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 22		skipping to change at page 15, line 22
	channel bindings do not match.		channel bindings do not match.
	Client and servers MUST set the "chan_binding" parameter in the calls		Client and servers MUST set the "chan_binding" parameter in the calls
	to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to		to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to
	NULL.		NULL.
	Implementations SHOULD set the "client_cbqops" and "server_cbqops" to		Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
	no security layer and instead depend on the session security afforded		no security layer and instead depend on the session security afforded
	by the bound-in channel.		by the bound-in channel.
	In order to accomodate the requirement in [16] "Authentication		In order to accomodate the requirement in [RFC5056] "Authentication
	frameworks and mechanisms that support channel binding MUST		frameworks and mechanisms that support channel binding MUST
	communicate channel binding failure to applications" implementations		communicate channel binding failure to applications" implementations
	MUST provide a way to communicate channel binding failures to		assert a bit in the security layer bitmask (see Section 9) on
	applications.		negotiation failures.
	Use of no SASL security layers in combination with channel binding		Use of no SASL security layers in combination with channel binding
	should provide better performance than using SASL security layers		should provide better performance than using SASL security layers
	over secure channels, and better security characteristics than using		over secure channels, and better security characteristics than using
	no SASL security layers over secure channels without channel binding.		no SASL security layers over secure channels without channel binding.
	For more discussions of channel bindings, and the syntax of the		For more discussions of channel bindings, and the syntax of the
	channel binding data for various security protocols, see [8]. For		channel binding data for various security protocols, see [RFC5056].
	easy reference, the channel binding format used for The Transport		For easy reference, the channel binding format used for The Transport
	Layer Security (TLS) Protocol [14] is specified in [16].		Layer Security (TLS) Protocol [RFC4346] is specified in
			[I-D.altman-tls-channel-bindings].
	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.
	skipping to change at page 16, line 44		skipping to change at page 16, line 44
	GS2_Wrap (client_qop | client_maxbuf | authzid)]		GS2_Wrap (client_qop | client_maxbuf | authzid)]
	S: Send [GSS_Accept_sec_context, ""] token		S: Send [GSS_Accept_sec_context, ""] token
	C: Send [GSS_Init_sec_context, ""] token		C: Send [GSS_Init_sec_context, ""] token
	...		...
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	GSS-API authentication is always initiated by the client. The SASL		GSS-API authentication is always initiated by the client. The SASL
	framework allows either the client and server to initiate		framework allows either the client and server to initiate
	authentication. In GS2 the server will send an initial empty		authentication. In GS2 the server will send an initial empty
	challenge (zero byte string) if it has not yet received a token from		challenge (zero byte string) if it has not yet received a token from
	the client. See section 3 of [2].		the client. See section 3 of [RFC4422].
	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: Empty Challenge		S: Empty Challenge
	C: Send [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 [GSS_Init_sec_context,		send [GSS_Init_sec_context,
	skipping to change at page 20, line 27		skipping to change at page 20, line 27
	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 is fatal.)		indications of out of order processing or replays is 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, or channel binding negotiation
			failed.
	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.
	8. 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.
	skipping to change at page 22, line 23		skipping to change at page 22, line 23
	layer.		layer.
	Note that "client_qop" and "server_qop" MAY indicate a quality of		Note that "client_qop" and "server_qop" MAY indicate a quality of
	protection that was not offered by the server and client,		protection that was not offered by the server and client,
	respectively. This SHOULD only be used when the server or client		respectively. This SHOULD only be used when the server or client
	(respectively) would otherwise fail the entire authentication		(respectively) would otherwise fail the entire authentication
	exchange. The server/client that receives a "client_qop"/		exchange. The server/client that receives a "client_qop"/
	"server_qop" MUST verify that it corresponds to an acceptable		"server_qop" MUST verify that it corresponds to an acceptable
	security level.		security level.
			Whether the channel binding negotiation is successful or not may
			influence the security layer selection. The most significant bit is
			used to signal failed channel binding negotiation. Implementations
			MUST set the bit if channel bindings were provided from the other end
			and a local channel binding is absent or not equal. Implementation
			MUST clear the bit otherwise.
	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.
			8-64 Reserved.
			128 Channel binding negotiation failed.
	Other bit-masks may be defined in the future; bits which are not		The bit-masks 8-64 are reserved and may be defined in the future;
	understood MUST be negotiated off.		bits which are not understood MUST be negotiated off.
	When decoding any received data with GSS_Unwrap the major_status		When decoding any received data with GSS_Unwrap the major_status
	other than the GSS_S_COMPLETE MUST be treated as a fatal error.		other than the GSS_S_COMPLETE MUST be treated as a fatal error.
	For integrity and confidentiality protection, GS2 negotiates the		For integrity and confidentiality protection, GS2 negotiates the
	maximum size of the output_message to send. Implementations can use		maximum size of the output_message to send. Implementations can use
	the GSS_Wrap_size_limit call to determine the corresponding maximum		the GSS_Wrap_size_limit call to determine the corresponding maximum
	size input_message.		size input_message.
	9.1. Examples		9.1. Examples
	When no security layer is negotiated the octet will encode an integer		When no security layer is negotiated the octet will encode an integer
	1 as follows.		1 as follows.
	0 1 2 3 4 5 6 7		7 6 5 4 3 2 1 0
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|0|0|0|0|0|0|0|1|		|0|0|0|0|0|0|0|1|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	When integrity is negotiated the octet will encode an integer 2 as		When integrity is negotiated the octet will encode an integer 2 as
	follows.		follows.
	0 1 2 3 4 5 6 7		7 6 5 4 3 2 1 0
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|0|0|0|0|0|0|1|0|		|0|0|0|0|0|0|1|0|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	When confidentiality is negotiated the octet will encode an integer 4		When confidentiality is negotiated, and channel binding negotiation
	as follows.		failed, the octet will encode an integer 128+4=132 as follows.
	0 1 2 3 4 5 6 7		7 6 5 4 3 2 1 0
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|0|0|0|0|0|1|0|0|		|1|0|0|0|0|1|0|0|
			+-+-+-+-+-+-+-+-+
			When a bitmask that indicates that all security layers are
			acceptable, the octet will encode an integer 1+2+4=7 as follows.
			7 6 5 4 3 2 1 0
			+-+-+-+-+-+-+-+-+
			|0|0|0|0|0|1|1|1|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	10. Non-integrity capable GSS-API mechanisms		10. Non-integrity capable GSS-API mechanisms
	Mechanisms that do not support integrity can be used with GS2, but		Mechanisms that do not support integrity can be used with GS2, but
	some security features cannot be provided, in particular including		some security features cannot be provided, in particular including
	channel bindings, security layers, and integrity protection of the		channel bindings, security layers, and integrity protection of the
	authorization identity.		authorization identity.
	Channel bindings and security layers MUST NOT be negotiated when the		Channel bindings and security layers MUST NOT be negotiated when the
	skipping to change at page 25, line 7		skipping to change at page 25, line 7
	GSS_Init_sec_context with a integ_req_flag of FALSE when it knows		GSS_Init_sec_context with a integ_req_flag of FALSE when it knows
	that the particular GSS-API mechanism will not be able to negotiate		that the particular GSS-API mechanism will not be able to negotiate
	per-message protection services.		per-message protection services.
	Implementations MAY have a policy to disallow non-integrity capable		Implementations MAY have a policy to disallow non-integrity capable
	mechanisms, and always call GSS_Init_sec_context with the		mechanisms, and always call GSS_Init_sec_context with the
	integ_req_flag set to TRUE.		integ_req_flag set to TRUE.
	11. Interoperability with the SASL "GSSAPI" mechanism		11. Interoperability with the SASL "GSSAPI" mechanism
	The Kerberos V5 GSS-API [10] mechanism is currently used in SASL		The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
	under the name "GSSAPI", see GSSAPI mechanism [12]. The Kerberos V5		under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The
	mechanism may also be used with the GS2 family. This causes an		Kerberos V5 mechanism may also be used with the GS2 family. This
	interopability problem, which is discussed and resolved below.		causes an interopability problem, which is discussed and resolved
			below.
	11.1. The interoperability problem		11.1. The interoperability problem
	If a client (or server) only support Kerberos V5 under the "GSSAPI"		If a client (or server) only support Kerberos V5 under the "GSSAPI"
	name and the server (or client) only support Kerberos V5 under the		name and the server (or client) only support Kerberos V5 under the
	GS2 family, the authentication negotiation will fail.		GS2 family, the authentication negotiation will fail.
	11.2. Resolving the problem		11.2. Resolving the problem
	If the Kerberos V5 mechanism is supported under GS2 in a server, the		If the Kerberos V5 mechanism is supported under GS2 in a server, the
	server SHOULD also support Kerberos V5 through the "GSSAPI"		server SHOULD also support Kerberos V5 through the "GSSAPI"
	mechanism, to avoid interoperability problems with older clients.		mechanism, to avoid interoperability problems with older clients.
	Reasons for violating this recommendation may include security		Reasons for violating this recommendation may include security
	considerations regarding the absent features in the GS2 mechanism.		considerations regarding the absent features in the GS2 mechanism.
	The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which		The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
	could enable certain tunnel attacks [18].		could enable certain tunnel attacks [mitm].
	11.3. Additional recommendations		11.3. Additional recommendations
	It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism		It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
	rather than through the "GSSAPI" mechanism, if both are available,		rather than through the "GSSAPI" mechanism, if both are available,
	because of the additional features in the GS2 mechanism.		because of the additional features in the GS2 mechanism.
	12. Mechanisms that negotiate other mechanisms		12. Mechanisms that negotiate other mechanisms
	A GSS-API mechanism that negotiate other mechanisms interact badly		A GSS-API mechanism that negotiate other mechanisms interact badly
	skipping to change at page 26, line 34		skipping to change at page 26, line 34
	negotiate mechanism X by using a GSS-API mechanism that negotiate		negotiate mechanism X by using a GSS-API mechanism that negotiate
	other mechanisms (such as SPNEGO), it may end up using mechanism Z		other mechanisms (such as SPNEGO), it may end up using mechanism Z
	when it ideally should have used mechanism Y. For this reason, the		when it ideally should have used mechanism Y. For this reason, the
	use of GSS-API mechanisms that negotiate other mechanisms are		use of GSS-API mechanisms that negotiate other mechanisms are
	disallowed under GS2.		disallowed under GS2.
	12.3. Resolving the problems		12.3. Resolving the problems
	GSS-API mechanisms that negotiate other mechanisms MUST NOT be used		GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
	with the GS2 SASL mechanism. This specifically exclude negotiating		with the GS2 SASL mechanism. This specifically exclude negotiating
	SPNEGO [11] under GS2.		SPNEGO [RFC4178] under GS2.
	The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [17]		The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech()
	can be used to identify such mechanisms.		[I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
			mechanisms.
	13. IANA Considerations		13. IANA Considerations
	The IANA is advised that SASL mechanism names starting with "GS2-"		The IANA is advised that SASL mechanism names starting with "GS2-"
	are reserved for SASL mechanisms which conform to this document. The		are reserved for SASL mechanisms which conform to this document. The
	IANA is directed to place a statement to that effect in the sasl-		IANA is directed to place a statement to that effect in the sasl-
	mechanisms registry.		mechanisms registry.
	Subject: Registration of SASL mechanism GS2-*		Subject: Registration of SASL mechanism GS2-*
	SASL mechanism prefix: GS2-		SASL mechanism prefix: GS2-
	skipping to change at page 28, line 22		skipping to change at page 28, line 22
	GSS-API mechanism widely on the Internet that do not support		GSS-API mechanism widely on the Internet that do not support
	integrity.		integrity.
	Because the negotiation of a particular GSS-API mechanism may be done		Because the negotiation of a particular GSS-API mechanism may be done
	in the clear, it is important for the GSS-API mechanisms to be		in the clear, it is important for the GSS-API mechanisms to be
	designed such that an active attacker cannot obtain an authentication		designed such that an active attacker cannot obtain an authentication
	with weaker security properties by modifying the challenges and		with weaker security properties by modifying the challenges and
	responses. This is a generic design critera for the GSS-API		responses. This is a generic design critera for the GSS-API
	mechanisms used under GS2.		mechanisms used under GS2.
			GS2 permits channel binding negotiation to fail. Implementation may
			have a local policy to reject authentication attempts in this case.
	When a server or client supports multiple GSS-API mechanisms, each of		When a server or client supports multiple GSS-API mechanisms, each of
	which has a different security strength, it is possible for an active		which has a different security strength, it is possible for an active
	attacker to cause a party to use the least secure mechanism		attacker to cause a party to use the least secure mechanism
	supported. This problem and a solution is discussed in section 6.1.2		supported. This problem and a solution is discussed in section 6.1.2
	of [2], but some additional methods to mitigate the problem include:		of [RFC4422], but some additional methods to mitigate the problem
			include:
	1. Use of an integrity protected transport, such as TLS [14]. To		1. Use of an integrity protected transport, such as TLS [RFC4346].
	protect against certain tunnel attacks [18], channel bindings		To protect against certain tunnel attacks [mitm], channel
	need to be used.		bindings need to be used.
	2. A client or server which supports mechanisms of different		2. A client or server which supports mechanisms of different
	strengths should have a configurable minimum strength that it		strengths should have a configurable minimum strength that it
	will use. It is not sufficient for this minimum strength check		will use. It is not sufficient for this minimum strength check
	to only be on the server, since an active attacker can change		to only be on the server, since an active attacker can change
	which mechanisms the client sees as being supported, causing the		which mechanisms the client sees as being supported, causing the
	client to send authentication credentials for its weakest		client to send authentication credentials for its weakest
	supported mechanism. This solution, however, is not guaranteed		supported mechanism. This solution, however, is not guaranteed
	to lead to the most secure mechanism supported by both parties,		to lead to the most secure mechanism supported by both parties,
	and is therefor only recommended as an additional precaution.		and is therefor only recommended as an additional precaution.
	The channel binding is sent without privacy protection and knowledge		The channel binding is sent without privacy protection and knowledge
	of it is assumed to provide no advantage to an attacker. This is a		of it is assumed to provide no advantage to an attacker. This is a
	property that has to be considered when specifying channel bindings		property that has to be considered when specifying channel bindings
	for a security protocol that will be used with GS2.		for a security protocol that will be used with GS2.
	When constructing the input_name_string, the client should not		When constructing the input_name_string, the client should not
	canonicalize the server's fully qualified domain name using an		canonicalize the server's fully qualified domain name using an
	insecure or untrusted directory service, such as the Domain Name		insecure or untrusted directory service, such as the Domain Name
	System [9] without DNSSEC [15].		System [RFC1034] without DNSSEC [RFC4033].
	The GS2 protocol hard code the SHA-1 algorithm for computing the		The GS2 protocol hard code the SHA-1 algorithm for computing the
	mechanism names. It is not possible to negotiate another hash		mechanism names. It is not possible to negotiate another hash
	algorithm. However, no traditional cryptographic hash properties		algorithm. However, no traditional cryptographic hash properties
	(such as collision resistance or pre-image resistance) are required		(such as collision resistance or pre-image resistance) are required
	nor assumed. The required and assumed property is that it is		nor assumed. The required and assumed property is that it is
	statistically unlikely that two different DER-encoded OID's share the		statistically unlikely that two different DER-encoded OID's share the
	same first 10 octets of the SHA-1 value. It is possible to		same first 10 octets of the SHA-1 value. It is possible to
	practically confirm that the SHA-1 algorithm has the necessary		practically confirm that the SHA-1 algorithm has the necessary
	property, by testing many different inputs.		property, by testing many different inputs.
	Additional security considerations are in the SASL and GSSAPI		Additional security considerations are in the SASL and GSSAPI
	specifications. Additional security considerations for the Kerberos		specifications. Additional security considerations for the Kerberos
	V5 GSSAPI mechanism can be found in [10]. We stress that service		V5 GSSAPI mechanism can be found in [RFC1964]. We stress that
	names should not be canonicalized using an unsecured directory		service names should not be canonicalized using an unsecured
	service such as the DNS without DNSSEC. Security issues are also		directory service such as the DNS without DNSSEC. Security issues
	discussed throughout this memo.		are also discussed throughout this memo.
	15. Acknowledgements		15. Acknowledgements
	The history of GS2 can be traced to the GSSAPI mechanism described in		The history of GS2 can be traced to the GSSAPI mechanism described in
	RFC 2222. The GSSAPI mechanism had some drawbacks, which created a		RFC 2222. The GSSAPI mechanism had some drawbacks, which created a
	need for an improved version. This document was derived from		need for an improved version. This document was derived from
	draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with		draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
	significant contributions from John G. Myers, although the majority		significant contributions from John G. Myers, although the majority
	of this document has been rewritten by the current author.		of this document has been rewritten by the current author.
	Contributions of many members of the SASL mailing list are gratefully		Contributions of many members of the SASL mailing list are gratefully
	acknowledged. In particular, ideas and feedback from Sam Hartman,		acknowledged. In particular, ideas and feedback from Sam Hartman,
	Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu		Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu
	improved the document and the protocol.		improved the document and the protocol.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and		[RFC4422] 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		[RFC2743] 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] National Institute of Standards and Technology, "Secure Hash		[FIPS.180-1.1995]
	Standard", FIPS PUB 180-1, April 1995,		National Institute of Standards and Technology, "Secure
			Hash Standard", FIPS PUB 180-1, April 1995,
	<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.		<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
	[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646",		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[7] International Telecommunications Union, "Information Technology		[ITU.X690.1994]
	- ASN.1 encoding rules: Specification of Basic Encoding Rules		International Telecommunications Union, "Information
	(BER), Canonical Encoding Rules (CER) and Distinguished		Technology - ASN.1 encoding rules: Specification of Basic
	Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.		Encoding Rules (BER), Canonical Encoding Rules (CER) and
			Distinguished Encoding Rules (DER)", ITU-T Recommendation
			X.690, 1994.
	[8] Williams, N., "On the Use of Channel Bindings to Secure		[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", draft-williams-on-channel-binding-04 (work in		Channels", RFC 5056, November 2007.
	progress), August 2007.
	16.2. Informative References		16.2. Informative References
	[9] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] 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,		[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
	June 1996.		RFC 1964, June 1996.
	[11] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The		[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
	Simple and Protected Generic Security Service Application		Simple and Protected Generic Security Service Application
	Program Interface (GSS-API) Negotiation Mechanism", RFC 4178,		Program Interface (GSS-API) Negotiation Mechanism",
	October 2005.		RFC 4178, October 2005.
	[12] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication		[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
	and Security Layer (SASL) Mechanism", RFC 4752, November 2006.		Authentication and Security Layer (SASL) Mechanism",
			RFC 4752, November 2006.
	[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",		[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
	RFC 2025, October 1996.		(SPKM)", RFC 2025, October 1996.
	[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)		[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	"DNS Security Introduction and Requirements", RFC 4033,		Rose, "DNS Security Introduction and Requirements",
	March 2005.		RFC 4033, March 2005.
	[16] Altman, J. and N. Williams, "On the Use of Channel Bindings to		[I-D.altman-tls-channel-bindings]
	Secure Channels", draft-altman-tls-channel-bindings-01 (work in		Altman, J. and N. Williams, "On the Use of Channel
	progress), December 2006.		Bindings to Secure Channels",
			draft-altman-tls-channel-bindings-01 (work in progress),
			December 2006.
	[17] Williams, N., "Extended Generic Security Service Mechanism		[I-D.ietf-kitten-extended-mech-inquiry]
	Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-02 (work		Williams, N., "Extended Generic Security Service Mechanism
	in progress), June 2006.		Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-02
			(work in progress), June 2006.
	[18] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in		[mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
	Tunneled Authentication",		in Tunneled Authentication",
	WWW http://www.saunalahti.fi/~asokan/research/mitm.html.		WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
	Author's Address		Author's Address
	Simon Josefsson		Simon Josefsson
	Email: simon@josefsson.org		Email: simon@josefsson.org
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 34, line 44		skipping to change at line 1170
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 60 change blocks.
	124 lines changed or deleted		153 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/