draft-ietf-sasl-gs2-15.txt		draft-ietf-sasl-gs2-16.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: February 1, 2010 Sun Microsystems		Expires: February 5, 2010 Sun Microsystems
	July 31, 2009		August 4, 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-15		draft-ietf-sasl-gs2-16
	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 February 1, 2010.		This Internet-Draft will expire on February 5, 2010.
	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 10, line 44		skipping to change at page 10, line 44
	The application-data field MUST be set to the gs2-header concatenated		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		with, when a gs2-cb-flag of "p" is used, the application's channel
	binding data.		binding data.
	5.2. Default Channel Binding		5.2. Default Channel Binding
	A default channel binding type agreement process for all SASL		A default channel binding type agreement process for all SASL
	application protocols that do not provide their own channel binding		application protocols that do not provide their own channel binding
	type agreement is provided as follows.		type agreement is provided as follows.
	Clients and servers MUST implement the "tls-unique" [tls-unique]		'tls-unique' is the default channel binding type for any application
	[I-D.altman-tls-channel-bindings] channel binding type. Clients and		that doesn't specify one.
	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.		Servers MUST implement the "tls-unique" [tls-unique]
	Conversely, clients MAY choose a different channel binding type based		[I-D.altman-tls-channel-bindings] channel binding type, if they
	on user input, configuration, or a future, as-yet undefined channel		implement any channel binding. Clients SHOULD implement the "tls-
	binding type negotiation protocol. Servers MUST choose the channel		unique" channel binding type, if they implement any channel binding.
	binding type indicated by the client, if they support it.		Clients and servers SHOULD choose the highest-layer/innermost end-to-
			end TLS channel as the channel to bind to.
			Servers MUST choose the channel binding type indicated by the client,
			or fail authentication if they don't 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: n,a=someuser,<initial context token with standard		C: n,a=someuser,<initial context token with standard
	header removed>		header removed>
	skipping to change at page 19, line 17		skipping to change at page 19, line 17
	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.		NOT choose the SPNEGO mechanism under any circumstances.
	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		[RFC5587] 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-"		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.
	The IANA is further advised that GS2 SASL mechanism names MUST NOT		The IANA is further advised that GS2 SASL mechanism names MUST NOT
	end in "-PLUS" except as a version of another mechanism name simply		end in "-PLUS" except as a version of another mechanism name simply
	skipping to change at page 23, line 15		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.
			[RFC5587] Williams, N., "Extended Generic Security Service Mechanism
			Inquiry APIs", RFC 5587, July 2009.
	[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-02 (work in progress), July 2009.		draft-ietf-sasl-scram-04 (work in progress), July 2009.
	[I-D.altman-tls-channel-bindings]		[I-D.altman-tls-channel-bindings]
	Altman, J., Williams, N., and L. Zhu, "Channel Bindings		Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", draft-altman-tls-channel-bindings-05 (work in		for TLS", draft-altman-tls-channel-bindings-05 (work in
	progress), June 2009.		progress), June 2009.
	[I-D.ietf-kitten-extended-mech-inquiry]
	Williams, N., "Extended Generic Security Service Mechanism
	Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06
	(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.
	Authors' Addresses		Authors' Addresses
	Simon Josefsson		Simon Josefsson
	SJD AB		SJD AB
	Hagagatan 24		Hagagatan 24
	Stockholm 113 47		Stockholm 113 47
End of changes. 9 change blocks.
	21 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/