draft-ietf-sasl-gs2-13.txt		draft-ietf-sasl-gs2-14.txt
	Network Working Group S. Josefsson		Network Working Group S. Josefsson
	Internet-Draft SJD AB		Internet-Draft SJD AB
	Intended status: Standards Track N. Williams		Intended status: Standards Track N. Williams
	Expires: November 27, 2009 Sun Microsystems		Expires: December 29, 2009 Sun Microsystems
	May 26, 2009		June 27, 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-13		draft-ietf-sasl-gs2-14
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	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 November 27, 2009.		This Internet-Draft will expire on December 29, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 14		skipping to change at page 3, line 14
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions used in this document . . . . . . . . . . . . . . 5		2. Conventions used in this document . . . . . . . . . . . . . . 5
	3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5		3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5
	3.2. Computing mechanism names manually . . . . . . . . . . . . 6		3.2. Computing mechanism names manually . . . . . . . . . . . . 6
	3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7		3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7
	4. SASL Authentication Exchange Message Format . . . . . . . . . 7		3.5. Which mechanism names to advertise and select . . . . . . 7
	4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7		4. SASL Authentication Exchange Message Format . . . . . . . . . 8
	5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9		5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Channel Binding to TLS Channels . . . . . . . . . . . . . 10		5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10
	7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 12		7. Authentication Conditions . . . . . . . . . . . . . . . . . . 13
	9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13
	10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 12		9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 14		10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 14
	11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 14		10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15
	11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 16		11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15
	12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 16		11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17
			12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17
	13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17		13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17
	13.1. The interoperability problem . . . . . . . . . . . . . . . 17		13.1. The interoperability problem . . . . . . . . . . . . . . . 17
	13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 17		13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18
	13.3. Additional Recommendations . . . . . . . . . . . . . . . . 17		13.3. Additional Recommendations . . . . . . . . . . . . . . . . 18
	14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18		14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18
	14.1. The interoperability problem . . . . . . . . . . . . . . . 18		14.1. The interoperability problem . . . . . . . . . . . . . . . 18
	14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18		14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18
	14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 18		14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 19
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	16. Security Considerations . . . . . . . . . . . . . . . . . . . 19		16. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20		17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	18.1. Normative References . . . . . . . . . . . . . . . . . . . 20		18.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	18.2. Informative References . . . . . . . . . . . . . . . . . . 21		18.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Generic Security Service Application Program Interface (GSS-API)		Generic Security Service Application Program Interface (GSS-API)
	[RFC2743] is a framework that provides security services to		[RFC2743] is a framework that provides security services to
	applications using a variety of authentication "mechanisms". Simple		applications using a variety of authentication mechanisms. Simple
	Authentication and Security Layer (SASL) [RFC4422] is a framework to		Authentication and Security Layer (SASL) [RFC4422] is a framework to
	provide authentication and "security layers" for connection based		provide authentication and security layers for connection based
	protocols, also using a variety of mechanisms. This document		protocols, also using a variety of mechanisms. This document
	describes how to use a GSS-API mechanism as though it were a SASL		describes how to use a GSS-API mechanism as though it were a SASL
	mechanism. This facility is called GS2 -- a moniker that indicates		mechanism. This facility is called GS2 -- a moniker that indicates
	that this is the second GSS-API->SASL mechanism bridge. The original		that this is the second GSS-API->SASL mechanism bridge. The original
	GSS-API->SASL mechanism bridge was specified by [RFC2222], now		GSS-API->SASL mechanism bridge was specified by [RFC2222], now
	[RFC4752]; we shall sometimes refer to the original bridge as GS1 in		[RFC4752]; we shall sometimes refer to the original bridge as GS1 in
	this document.		this document.
	All GSS-API mechanisms are implicitly registered for use within SASL		All GSS-API mechanisms are implicitly registered for use within SASL
	by this specification. The SASL mechanisms defined in this document		by this specification. The SASL mechanisms defined in this document
	skipping to change at page 4, line 43		skipping to change at page 4, line 43
	In particular, the current consensus of the SASL community appears to		In particular, the current consensus of the SASL community appears to
	be that SASL "security layers" (i.e., confidentiality and integrity		be that SASL "security layers" (i.e., confidentiality and integrity
	protection of application data after authentication) are too complex		protection of application data after authentication) are too complex
	and, since SASL applications tend to have an option to run over a		and, since SASL applications tend to have an option to run over a
	Transport Layer Security (TLS) [RFC5246] channel, redundant and best		Transport Layer Security (TLS) [RFC5246] channel, redundant and best
	replaced with channel binding.		replaced with channel binding.
	GS2 is designed to be as simple as possible. It adds to GSS-API		GS2 is designed to be as simple as possible. It adds to GSS-API
	security context token exchanges only the bare minimum to support		security context token exchanges only the bare minimum to support
	SASL semantics and negotiation of use of channel binding.		SASL semantics and negotiation of use of channel binding.
	Specifically, GS2 adds a small header (2 bytes or 3 bytes plus the		Specifically, GS2 adds a small header (a few bytes plus the length of
	length of the client requested SASL authorization ID (authzid)) to		the client requested SASL authorization identity) to the initial GSS-
	the initial context token and to the application channel binding		API context token and to the application channel binding data. GS2
	data, and it uses SASL mechanism negotiation to implement channel		uses SASL mechanism negotiation to implement channel binding
	binding negotiation. All GS2 plaintext is protected via the use of		negotiation. All GS2 plaintext is protected via the use of GSS-API
	GSS-API channel binding. Additionally, to simplify the		channel binding. Additionally, to simplify the implementation of GS2
	implementation of GS2 mechanisms for implementors who will not		mechanisms for implementors who will not implement a GSS-API
	implement a GSS-API framework, we compress the initial security		framework, we compress the initial security context token header
	context token header required by [RFC2743] (see section 3.1).		required by [RFC2743] (see section 3.1).
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
			The document uses many terms and function names defined in [RFC2743]
			as updated by [RFC5554].
	3. Mechanism name		3. Mechanism name
	There are two SASL mechanism names for any GSS-API mechanism used		There are two SASL mechanism names for any GSS-API mechanism used
	through this facility. One denotes that the server supports channel		through this facility. One denotes that the server supports channel
	binding. The other denotes that it does not.		binding. The other denotes that it does not.
	The SASL mechanism name for a GSS-API mechanism is that which is		The SASL mechanism name for a GSS-API mechanism is that which is
	provided by that mechanism when it was specified, if one was		provided by that mechanism when it was specified, if one was
	specified. This name denotes that the server does not support		specified. This name denotes that the server does not support
	channel binding. Add the suffix "-PLUS" and the resulting name		channel binding. Add the suffix "-PLUS" and the resulting name
	skipping to change at page 6, line 9		skipping to change at page 6, line 9
	not relevant to this use of Base32. If any padding or non-alphabet		not relevant to this use of Base32. If any padding or non-alphabet
	characters are encountered, the name is not a GS2 family mechanism		characters are encountered, the name is not a GS2 family mechanism
	name. This name denotes that the server does not support channel		name. This name denotes that the server does not support channel
	binding. Add the suffix "-PLUS" and the resulting name denotes that		binding. Add the suffix "-PLUS" and the resulting name denotes that
	the server does support channel binding.		the server does support channel binding.
	3.2. Computing mechanism names manually		3.2. Computing mechanism names manually
	The hash-derived GS2 SASL mechanism name may be computed manually.		The hash-derived GS2 SASL mechanism name may be computed manually.
	This is useful when the set of supported GSS-API mechanisms is known		This is useful when the set of supported GSS-API mechanisms is known
	in advance. It also obliterate the need to implement Base32, SHA-1		in advance. This obliterate the need to implement Base32, SHA-1 and
	and DER in the SASL mechanism. The computed mechanism name can be		DER in the SASL mechanism. The computed mechanism name can be used
	used directly in the implementation, and the implementation need not		directly in the implementation, and the implementation need not
	concern itself with that the mechanism is part of a mechanism family.		concern itself with that the mechanism is part of a mechanism family.
	3.3. Examples		3.3. Examples
	The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The		The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The
	ASN.1 DER encoding of the OID, including the tag and length, is (in		ASN.1 DER encoding of the OID, including the tag and length, is (in
	hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER		hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER
	encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56		encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56
	27 86 61 ad. Convert the first 7 octets to binary, drop the last		27 86 61 ad. Convert the first 7 octets to binary, drop the last
	bit, and re-group them in groups of 5, and convert them back to		bit, and re-group them in groups of 5, and convert them back to
	skipping to change at page 7, line 37		skipping to change at page 7, line 37
	mechanism name.		mechanism name.
	3.4. Grandfathered mechanism names		3.4. Grandfathered mechanism names
	Some older GSS-API mechanisms were not specified with a SASL GS2		Some older GSS-API mechanisms were not specified with a SASL GS2
	mechanism name. Using a shorter name can be useful nonetheless. We		mechanism name. Using a shorter name can be useful nonetheless. We
	specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5		specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5
	mechanism, to be used as if the original specification documented it.		mechanism, to be used as if the original specification documented it.
	See Section 15.		See Section 15.
	4. SASL Authentication Exchange Message Format		3.5. Which mechanism names to advertise and select
	4.1. SASL Messages		Servers SHOULD advertise both non-PLUS and the PLUS-variant of a GS2
			mechanism name. If the server cannot support channel binding, it MAY
			advertise only the non-PLUS variant. If the server would never
			succeed authentication of the non-PLUS variant due to policy reasons,
			it MAY advertise only the PLUS-variant.
			If the client negotiates mechanisms then clients MUST select the
			PLUS-variant if offered by the server. Otherwise, if the client does
			not negotiate mechanisms then it MUST use the non-PLUS variant.
			4. SASL Authentication Exchange Message Format
	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.
	This number is the same as the number of context tokens that the GSS-		On success, this number is the same as the number of context tokens
	API mechanism would normally require in order to establish a security		that the GSS-API mechanism would normally require in order to
	context (or to fail to do so).		establish a security context. On failures, the exchange can be
			terminated early by any party.
	Note that when using a GS2 mechanism the SASL client is always a GSS-		When using a GS2 mechanism the SASL client is always a GSS-API
	API initiator and the SASL server is always a GSS-API acceptor. Thus		initiator and the SASL server is always a GSS-API acceptor. The
	the SASL client calls GSS_Init_sec_context and the server calls		client calls GSS_Init_sec_context and the server calls
	GSS_Accept_sec_context.		GSS_Accept_sec_context.
	All the SASL authentication messages exchanged are exactly the same		All the SASL authentication messages exchanged are exactly the same
	as the security context tokens of the GSS-API mechanism, except for		as the security context tokens of the GSS-API mechanism, except for
	the initial security context token.		the initial security context token.
	The client and server MAY send GSS-API error tokens (tokens output by		The client and server MAY send GSS-API error tokens (tokens output by
	GSS_Init_sec_context() or GSS_Accept_sec_context() when the major		GSS_Init_sec_context() or GSS_Accept_sec_context() when the major
	status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED).		status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED).
	As this indicate an error condition, after sending the token, the		As this indicate an error condition, after sending the token, the
	skipping to change at page 8, line 42		skipping to change at page 9, line 21
	UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4		UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4
	saslname = 1*(UTF8-char-safe / "=2C" / "=3D")		saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
	gs2-authzid = "a=" saslname		gs2-authzid = "a=" saslname
	;; GS2 has to transport an authzid since		;; GS2 has to transport an authzid since
	;; the GSS-API has no equivalent		;; the GSS-API has no equivalent
	gs2-nonstd-flag = "F"		gs2-nonstd-flag = "F"
	;; "F" means the mechanism is not a		;; "F" means the mechanism is not a
	;; standard GSS-API mechanism in that the		;; standard GSS-API mechanism in that the
	;; RFC2743 section 3.1 header was missing		;; RFC2743 section 3.1 header was missing
	gs2-cb-flag = "p" / "n" / "y"		cb-name = 1*(ALPHA / DIGIT / "." / "-")
			;; See RFC 5056 section 7
			gs2-cb-flag = "p=" cb-name / "n" / "y"
	;; GS2 channel binding (CB) flag		;; GS2 channel binding (CB) flag
	;; "p" -> client supports and used CB		;; "p" -> client supports and used CB
	;; "n" -> client does not support CB		;; "n" -> client does not support CB
	;; "y" -> client supports CB, thinks the server		;; "y" -> client supports CB, thinks the server
	;; does not		;; does not
	gs2-header = [gs2-nonstd-flag] gs2-cb-flag [gs2-authzid] ","		gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
	;; The GS2 header is gs2-header.		;; The GS2 header is gs2-header.
	When the "gs2-nonstd-flag" flag is present, the client did not find/		When the "gs2-nonstd-flag" flag is present, the client did not find/
	remove a [RFC2743] section 3.1 token header from the initial token		remove a [RFC2743] section 3.1 token header from the initial token
	returned by GSS_Init_sec_context. This signals to the server that it		returned by GSS_Init_sec_context. This signals to the server that it
	MUST NOT re-add the data that is normally removed by the client.		MUST NOT re-add the data that is normally removed by the client.
	The "gs2-cb-flag" signals the channel binding mode. One of "p", "n",		The "gs2-cb-flag" signals the channel binding mode. One of "p", "n",
	or "y" is used. A "p" means the client supports and used a channel		or "y" is used. A "p" means the client supports and used a channel
	binding. A "n" means that the client does not support channel		binding, and the name of the channel binding type is indicated. A
	binding. A "y" means the client supports channel binding, but		"n" means that the client does not support channel binding. A "y"
	believes the server does not, so it did not use a channel binding.		means the client supports channel binding, but believes the server
	See the next section for more details.		does not support it, so it did not use a channel binding. See the
			next section for more details.
	The "gs2-authzid" holds the SASL authorization identity. It is		The "gs2-authzid" holds the SASL authorization identity. It is
	encoded using UTF-8 [RFC3629] with three exceptions:		encoded using UTF-8 [RFC3629] with three exceptions:
	o The NUL characters is forbidden as required by section 3.4.1 of		o The NUL characters is forbidden as required by section 3.4.1 of
	[RFC4422].		[RFC4422].
	o The server MUST replace any "," (comma) in the string with "=2C".		o The server MUST replace any "," (comma) in the string with "=2C".
	o The server MUST replace any "=" (equals) in the string with "=3D".		o The server MUST replace any "=" (equals) in the string with "=3D".
	If a server sends a string that does not conform to this syntax, the
	client MUST reject authentication.
	5. Channel Bindings		5. Channel Bindings
	If the server supports channel binding then it MUST list both forms		If the client does not support channel binding then it MUST use a "n"
	of the SASL mechanism name for each GSS-API mechanism supported via		gs2-cb-flag.
	GS2 (i.e., GSS-API mechanisms that support channel binding).
	If the client supports channel binding and the server does not (i.e.,		If the client supports channel binding and the server does not appear
	the server did not advertise the -PLUS names) then the client MUST		to (i.e., the client did not see a -PLUS name) then the client MUST
	either fail authentication or it MUST set the channel binding flag in		either fail authentication or it MUST chose the non-PLUS mechanism
	the GS2 initial security context token to "y" and MUST NOT include		name and use a "y" gs2-cb-flag.
	application channel binding data in the GSS-API channel binding input
	to GSS_Init_sec_context.
	If the client supports channel binding and the server also does then		If the client supports channel binding and the server appears to
	the client MUST set the channel binding flag in the GS2 initial		support it (i.e., the client see a -PLUS name) then the client MUST
	security context token to "p" and MUST include application channel		use a "p" gs2-cb-flag to indicate the channel binding type it is
	binding data in the GSS-API channel binding input to		using.
	GSS_Init_sec_context. This is done by pre-pending the gs2-header to
	the application's channel binding data. If the application did not
	provide channel binding data then the GS2 header is used as though it
	were application-provided channel binding data.
	If the client does not support channel binding then it MUST set the		The client generate the chan_bindings input parameter for
	channel binding flag in the GS2 initial security context token to "n"		GSS_Init_sec_context as described below.
	and MUST NOT include application channel binding data in the GSS-API
	channel binding input to GSS_Init_sec_context.
	Upon receipt of the initial authentication message the server checks		Upon receipt of the initial authentication message the server checks
	the channel binding flag in the GS2 header and constructs a channel		the gs2-cb-flag in the GS2 header and constructs a chan_bindings
	binding data input for GSS_Accept_sec_context accordingly. If the		parameter for GSS_Accept_sec_context as described below. If the
	client channel binding flag was "n" then the server MUST NOT include		client channel binding flag was "y" and the server did advertise
	application channel binding data in the GSS-API channel binding input		support for channel bindings then the server MUST fail
	to GSS_Accept_sec_context. If the client channel binding flag was		authentication. If the client channel binding flag was "p" and the
	"y" and the server does support channel binding then the server MUST		server does not support the indicated channel binding type then the
	fail authentication. If the client channel binding flag was "p" the		server MUST fail authentication.
	server MUST include application channel binding data in the GSS-API
	channel binding input to GSS_Accept_sec_context.
	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 [RFC5056].		channel binding data for various security protocols, see [RFC5056].
	5.1. Channel Binding to TLS Channels		5.1. Content of GSS-CHANNEL-BINDINGS structure
	If an external TLS channel is to be bound into the GS2		The calls to GSS_Init_sec_context and GSS_Accept_sec_context takes a
	authentication, and if the channel was established using a X.509		chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS
	[RFC5280] server certificate to authenticate the server, then the GS2		structure [RFC5554].
	client and server MUST use the 'tls-server-end-point' channel binding
	type. See the IANA Channel Binding Types registry.
	If an external TLS channel is to be bound into the GS2		The initiator-address-type and acceptor-address-type fields of the
	authentication, and if the channel was established either without the		GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-
	use of any X.509 server certificate to authenticate the server, or		address and acceptor-address fields MUST be the empty string.
	with a non X.509 server certificate, then the GS2 client and server
	MUST use the 'tls-unique' channel binding type.		The application-data field MUST be set to the gs2-header concatenated
			with, when a gs2-cb-flag of "p" is used, the application's channel
			binding data (if any).
			5.2. Default Channel Binding
			A default channel binding type agreement process for all SASL
			application protocols that do not provide their own channel binding
			type agreement is provided as follows.
			Clients and servers MUST implement the "tls-unique" [tls-unique]
			channel binding type. Clients and servers SHOULD choose the highest-
			layer/innermost end-to-end TLS channel as the channel to bind to.
			Clients SHOULD choose the tls-unique channel binding type.
			Conversely, clients MAY choose a different channel binding type based
			on user input, configuration, or a future, as-yet undefined channel
			binding type negotiation protocol. Servers MUST choose the channel
			binding type indicated by the client, if they support it.
	6. Examples		6. Examples
	Example #1: a one round-trip GSS-API context token exchange, no		Example #1: a one round-trip GSS-API context token exchange, no
	channel binding, optional authzid given.		channel binding, optional authzid given.
	C: Request authentication exchange		C: Request authentication exchange
	S: Empty Challenge		S: Empty Challenge
	C: na=someuser,<initial context token with standard		C: n,a=someuser,<initial context token with standard
	header removed>		header removed>
	S: Send reply context token as is		S: Send reply context token as is
	C: Empty message		C: Empty message
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Example #2: a one and one half round-trip GSS-API context token		Example #2: a one and one half round-trip GSS-API context token
	exchange.		exchange, no channel binding.
	C: Request authentication exchange		C: Request authentication exchange
	S: Empty Challenge		S: Empty Challenge
	C: na=someuser,<initial context token with standard		C: n,<initial context token with standard
	header removed>		header removed>
	S: Send reply context token as is		S: Send reply context token as is
	C: Send reply context token as is		C: Send reply context token as is
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Example #3: a two round-trip GSS-API context token exchange, no		Example #3: a two round-trip GSS-API context token exchange, no
	standard token header.		channel binding, no standard token header.
	C: Request authentication exchange		C: Request authentication exchange
	S: Empty Challenge		S: Empty Challenge
	C: Fna=someuser,<initial context token without		C: F,n,<initial context token without
	standard header>		standard header>
	S: Send reply context token as is		S: Send reply context token as is
	C: Send reply context token as is		C: Send reply context token as is
	S: Send reply context token as is		S: Send reply context token as is
	C: Empty message		C: Empty message
	S: Outcome of authentication exchange		S: Outcome of authentication exchange
	Example #4: using channel binding		Example #4: using channel binding, optional authzid given.
	C: Request authentication exchange		C: Request authentication exchange
	S: Empty Challenge		S: Empty Challenge
	C: pa=someuser,<initial context token with standard		C: p=tls-unique,a=someuser,<initial context token with standard
			header removed>
			S: Send reply context token as is
			...
			Example #5: using channel binding.
			C: Request authentication exchange
			S: Empty Challenge
			C: p=tls-unique,<initial context token with standard
			header removed>
			S: Send reply context token as is
			...
			Example #6: using non-standard channel binding (requires out-of-band
			negotiation).
			C: Request authentication exchange
			S: Empty Challenge
			C: p=tls-server-end-point,<initial context token with standard
	header removed>		header removed>
	S: Send reply context token as is		S: Send reply context token as is
	...		...
			Example #7: client supports channel bindings but server does not,
			optional authzid given.
			C: Request authentication exchange
			S: Empty Challenge
			C: y,a=someuser,<initial
			context token with standard header removed>
			S: Send reply context token as is
			...
	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 [RFC4422].		the client. See section 3 of [RFC4422].
	7. Authentication Conditions		7. Authentication Conditions
	Authentication MUST NOT succeed if any one of the following		Authentication MUST NOT succeed if any one of the following
	conditions are true:		conditions are true:
	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 If the client's initial GS2 header does not match the ABNF.
			o In particular, if the initial character of the client message is
			anything except "F", "p", "n", or "y".
	o If the client's GS2 channel binding flag was "y" and the server		o If the client's GS2 channel binding flag was "y" and the server
	supports channel binding.		supports channel bindings.
			o If the client's GS2 channel binding flag was "p" and the server
			does not support the indicated channel binding.
	o If the client requires use of channel binding and the server did		o If the client requires use of channel binding and the server did
	not advertise support for channel binding.		not advertise support for channel binding.
	o Authorization of client principal (i.e., src_name in		o Authorization of client principal (i.e., src_name in
	GSS_Accept_sec_context) to requested authzid failed.		GSS_Accept_sec_context) to requested authzid failed.
	o If the client is not authorized to the requested authzid or an		o If the client is not authorized to the requested authzid or an
	authzid could not be derived from the client's initiator principal		authzid could not be derived from the client's initiator principal
	name.		name.
	8. GSS-API Parameters		8. GSS-API Parameters
	skipping to change at page 16, line 34		skipping to change at page 17, line 34
	Mechanism specific status code.		Mechanism specific status code.
	Function value: GSS status code		Function value: GSS status code
	GSS_S_COMPLETE Successful completion		GSS_S_COMPLETE Successful completion
	GSS_S_BAD_MECH The desired_mech OID is unsupported		GSS_S_BAD_MECH The desired_mech OID is unsupported
	12. Security Layers		12. Security Layers
	GS2 does not currently support SASL security layers. Applications		GS2 does not support SASL security layers. Applications that need
	that need integrity protection or confidentiality and integrity		integrity or confidentiality protection can use either channel
	protection MUST use either channel binding to a secure external		binding to a secure external channel or another SASL mechanism that
	channel or a SASL mechanism that does provide security layers.		does provide security layers.
	NOTE WELL: the GS2 client's first authentication message MUST always
	start with "F", "p", "n" or "y", otherwise the server MUST fail
	authentication. This will allow us to add support for security
	layers in the future if it were to become necessary. Note that
	adding security layer support to GS2 must not break existing SASL/GS2
	applications, which can be accomplished by making security layers
	optional.
	[A sketch of how to add sec layer support... Add a way for the
	client to: a) make an offer of sec layers and max buffer, b) make an
	opportunistic selection of sec layer and buffer size, both in the
	first client authentication message, and starting with a character
	other than "F", "n", "y" or "p". The server could accept the
	opportunistic proposal (reply token prefixed with a byte indicating
	acceptance) or reject it along with an indication of the server's
	acceptable sec layers and max buffer size. In the latter case the
	GSS-API security context token exchange must be abandoned and
	recommenced, although this would be a detail of the GS2 bridge not
	exposed to the SASL application. The negotiation would be protected
	via GSS channel binding, as with the rest of GS2.]
	13. Interoperability with the SASL GSSAPI mechanism		13. Interoperability with the SASL GSSAPI mechanism
	The Kerberos V5 GSS-API [RFC1964] 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 [RFC4752]. The Kerberos		under the name GSSAPI, see GSSAPI mechanism [RFC4752]. The Kerberos
	V5 mechanism may also be used with the GS2 family. This causes an		V5 mechanism may also be used with the GS2 family. This causes an
	interoperability problem, which is discussed and resolved below.		interoperability problem, which is discussed and resolved below.
	13.1. The interoperability problem		13.1. The interoperability problem
	skipping to change at page 18, line 37		skipping to change at page 19, line 14
	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.
	14.3. Resolving the problems		14.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. Specifically SPNEGO [RFC4178] MUST NOT		with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
	be used as a GS2 mechanism. To make this easier for SASL		be used as a GS2 mechanism. To make this easier for SASL
	implementations we assign a symbolic SASL mechanism name to the		implementations we assign a symbolic SASL mechanism name to the
	SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST		SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST
	NOT choose the SPNEGO mechanism under any circumstances. [What about		NOT choose the SPNEGO mechanism under any circumstances.
	SASL apps that don't do mechanism negotiation? Probably none exist.
	But if any did then presumably it would OK to use the SPNEGO
	mechanism, no? -Nico]
	The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech		The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech
	[I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such		[I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
	mechanisms.		mechanisms.
	15. IANA Considerations		15. IANA Considerations
			The IANA is advised that SASL mechanism names starting with "GS2-"
			are reserved for SASL mechanisms which conform to this document. The
			IANA is directed to place a statement to that effect in the sasl-
			mechanisms registry.
			The IANA is further advised that GS2 SASL mechanism names MUST NOT
			end in "-PLUS" except as a version of another mechanism name simply
			suffixed with "-PLUS".
	The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121]		The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121]
	[RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS".		[RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS".
	The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be		The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be
	"SPNEGO" and "SPNEGO-PLUS". As described in Section 14 the SASL		"SPNEGO" and "SPNEGO-PLUS". As described in Section 14 the SASL
	"SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are		"SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are
	provided as a convenience for SASL library implementors.		provided as a convenience for SASL library implementors.
	The IANA is advised that SASL mechanism names starting with "GS2-"
	are reserved for SASL mechanisms which conform to this document. The
	IANA is directed to place a statement to that effect in the sasl-
	mechanisms registry.
	The IANA is further advised that SASL mechanisms MUST NOT end in
	"-PLUS" except as a version of another mechanism name simply suffixed
	with "-PLUS".
	Subject: Registration of SASL mechanism GS2-*		Subject: Registration of SASL mechanism GS2-*
	SASL mechanism prefix: GS2-		SASL mechanism prefix: GS2-
	Security considerations: RFC [THIS-DOC]		Security considerations: RFC [THIS-DOC]
	Published specification: RFC [THIS-DOC]		Published specification: RFC [THIS-DOC]
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Simon Josefsson <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.
	skipping to change at page 20, line 23		skipping to change at page 20, line 48
	When constructing the input_name_string for GSS_Import_name with the		When constructing the input_name_string for GSS_Import_name with the
	GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT		GSS_C_NT_HOSTBASED_SERVICE name type, 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 [RFC1034] without DNSSEC [RFC4033].		System [RFC1034] without DNSSEC [RFC4033].
	GS2 does not directly use any cryptographic algorithms, therefore it		GS2 does not directly use any cryptographic algorithms, therefore it
	is automatically "algorithm agile", or, as agile as the GSS-API		is automatically "algorithm agile", or, as agile as the GSS-API
	mechanisms that are available for use in SASL applications via GS2.		mechanisms that are available for use in SASL applications via GS2.
			The exception is the use of SHA-1 for deriving SASL mechanism names,
			but no cryptographic properties are required. The required property
			is that the truncated output for distinct inputs are different for
			practical input values.
			GS2 does not protect against downgrade attacks of channel binding
			types. The complexities of negotiation a channel binding type, and
			handling down-grade attacks in that negotiation, was intentionally
			left out of scope for this document.
	The security considerations of SASL [RFC4422], the GSS-API [RFC2743],		The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
	channel binding [RFC5056], any external channels (such as TLS,		channel binding [RFC5056], any external channels (such as TLS,
	[RFC5246], channel binding types (see the IANA channel binding type		[RFC5246], channel binding types (see the IANA channel binding type
	registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism		registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism
	[RFC4121] [RFC1964]), may also apply.		[RFC4121] [RFC1964]), also apply.
	17. Acknowledgements		17. Acknowledgements
	The history of GS2 can be traced to the "GSSAPI" mechanism originally		The history of GS2 can be traced to the "GSSAPI" mechanism originally
	specified by RFC2222. This document was derived from		specified by RFC2222. 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 authors.		of this document has been rewritten by the current authors.
	Contributions of many members of the SASL mailing list are gratefully		Contributions of many members of the SASL mailing list are gratefully
	skipping to change at page 21, line 26		skipping to change at page 22, line 12
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure		[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", RFC 5056, November 2007.		Channels", RFC 5056, November 2007.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
			[RFC5554] Williams, N., "Clarifications and Extensions to the
			Generic Security Service Application Program Interface
			(GSS-API) for the Use of Channel Bindings", RFC 5554,
			May 2009.
	[CCITT.X690.2002]		[CCITT.X690.2002]
	International International Telephone and Telegraph		International International Telephone and Telegraph
	Consultative Committee, "ASN.1 encoding rules:		Consultative Committee, "ASN.1 encoding rules:
	Specification of basic encoding Rules (BER), Canonical		Specification of basic encoding Rules (BER), Canonical
	encoding rules (CER) and Distinguished encoding rules		encoding rules (CER) and Distinguished encoding rules
	(DER)", CCITT Recommendation X.690, July 2002.		(DER)", CCITT Recommendation X.690, July 2002.
			[tls-unique]
			Zhu, L., "Registration of TLS unique channel binding
			(generic)", July 2008.
	18.2. Informative References		18.2. Informative References
	[RFC1034] 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.
	[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",		[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
	RFC 1964, June 1996.		RFC 1964, June 1996.
	[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism		[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
	(SPKM)", RFC 2025, October 1996.		(SPKM)", RFC 2025, October 1996.
	skipping to change at page 22, line 19		skipping to change at page 23, line 15
	Program Interface (GSS-API) Negotiation Mechanism",		Program Interface (GSS-API) Negotiation Mechanism",
	RFC 4178, October 2005.		RFC 4178, October 2005.
	[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple		[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
	Authentication and Security Layer (SASL) Mechanism",		Authentication and Security Layer (SASL) Mechanism",
	RFC 4752, November 2006.		RFC 4752, November 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.
	[I-D.ietf-sasl-scram]		[I-D.ietf-sasl-scram]
	Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams,		Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams,
	"Salted Challenge Response (SCRAM) SASL Mechanism",		"Salted Challenge Response (SCRAM) SASL Mechanism",
	draft-ietf-sasl-scram-00 (work in progress), May 2009.		draft-ietf-sasl-scram-01 (work in progress), May 2009.
	[I-D.ietf-kitten-extended-mech-inquiry]		[I-D.ietf-kitten-extended-mech-inquiry]
	Williams, N., "Extended Generic Security Service Mechanism		Williams, N., "Extended Generic Security Service Mechanism
	Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06		Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06
	(work in progress), April 2009.		(work in progress), April 2009.
	[mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle		[mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
	in Tunneled Authentication",		in Tunneled Authentication",
	WWW http://www.saunalahti.fi/~asokan/research/mitm.html.		WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
End of changes. 49 change blocks.
	154 lines changed or deleted		196 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/