draft-ietf-kitten-2478bis-01.txt		draft-ietf-kitten-2478bis-02.txt
	NETWORK WORKING GROUP L. Zhu		NETWORK WORKING GROUP L. Zhu
	Internet-Draft P. Leach		Internet-Draft P. Leach
	Obsoletes: 2478 (if approved) K. Jaganathan		Obsoletes: 2478 (if approved) K. Jaganathan
	Expires: May 26, 2005 Microsoft Corporation		Expires: June 1, 2005 Microsoft Corporation
	W. Ingersoll		W. Ingersoll
	Sun Microsystems		Sun Microsystems
	November 25, 2004		December 1, 2004
	The Simple and Protected GSS-API Negotiation Mechanism		The Simple and Protected GSS-API Negotiation Mechanism
	draft-ietf-kitten-2478bis-01		draft-ietf-kitten-2478bis-02
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any 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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 May 26, 2005.		This Internet-Draft will expire on June 1, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document specifies a negotiation mechanism for the Generic		This document specifies a negotiation mechanism for the Generic
	Security Service Application Program Interface (GSS-API) which is		Security Service Application Program Interface (GSS-API) which is
	described in RFC 2743.		described in RFC 2743.
	skipping to change at page 2, line 31		skipping to change at page 2, line 31
	6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16		6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	10. Normative References . . . . . . . . . . . . . . . . . . . . 19		10. Normative References . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
	A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 21		A. GSS-API Negotiation Support API . . . . . . . . . . . . . . . 21
	A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21		A.1 GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21
	A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21		A.2 GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21
	B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 23		B. Changes since RFC2478 . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . 25
	1. Introduction		1. Introduction
	The GSS-API [RFC2743] provides a generic interface which can be		The GSS-API [RFC2743] provides a generic interface which can be
	layered atop different security mechanisms such that if communicating		layered atop different security mechanisms such that if communicating
	peers acquire GSS-API credentials for the same security mechanism,		peers acquire GSS-API credentials for the same security mechanism,
	then a security context may be established between them (subject to		then a security context may be established between them (subject to
	policy). However, GSS-API doesn't prescribe the method by which		policy). However, GSS-API does not prescribe the method by which
	GSS-API peers can establish whether they have a common security		GSS-API peers can establish whether they have a common security
	mechanism.		mechanism.
	The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism		The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
	defined here is a pseudo security mechanism, represented by the		defined here is a pseudo security mechanism, represented by the
	Object Identifier iso.org.dod.internet.security.mechanism.snego		Object Identifier iso.org.dod.internet.security.mechanism.snego
	(1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band		(1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
	whether their credentials share common GSS-API security mechanism(s),		whether their credentials share common GSS-API security mechanism(s),
	and if so, to invoke normal security context establishment for a		and if so, to invoke normal security context establishment for a
	selected common security mechanism. This is most useful for		selected common security mechanism. This is most useful for
	applications that are based on GSS-API implementations and multiple		applications which are based on GSS-API implementations and share
	mechanisms are shared between the peers.		multiple mechanisms between the peers.
	The SPNEGO mechanism negotiation is based on the following		The SPNEGO mechanism negotiation is based on the following
	negotiation model: the initiator proposes a list of security		negotiation model: the initiator proposes a list of security
	mechanism(s), in its preference order (favorite choice first), the		mechanism(s), in decreasing preference order (favorite choice first),
	acceptor (also known as the target) either accepts the initiator's		the acceptor (also known as the target) either accepts the
	preferred security mechanism (the first in the list), or chooses one		initiator's preferred security mechanism (the first in the list), or
	that is available from the offered list, or rejects the proposed		chooses one that is available from the offered list, or rejects the
	value(s). The target then informs the initiator of its choice.		proposed value(s). The target then informs the initiator of its
			choice.
	Once a common security mechanism is chosen, it MAY also negotiate		Once a common security mechanism is chosen, mechanism-specific
	mechanism-specific options during its context establishment, but that		options MAY be negotiated as part of the selected mechanism's context
	will be inside the mechanism tokens and invisible to this protocol.		establishment. These negotiations (if any) are internal to the
			mechanism and opaque to the SPNEGO protocol. As such they are
			outside the scope of this document.
	If per-message integrity services are available on the established		If per-message integrity services are available on the established
	mechanism security context, the peers can then exchange MIC tokens to		mechanism security context, then the peers can exchange MIC tokens to
	ensure that the mechanism list was not tampered with. This MIC token		ensure that the mechanism list was not tampered with. This MIC token
	exchange is OPTIONAL if no interference could have material impact on		exchange is OPTIONAL if the selected mechanism is the most preferred
	the negotiation, i.e., when the selected mechanism is the first		choice of both peers (see Section 5).
	choice for both peers.
	In order to avoid an extra round trip, the first security token of		In order to avoid an extra round trip, the first security token of
	the preferred mechanism SHOULD be embedded in the initial negotiation		the initiator's preferred mechanism SHOULD be embedded in the initial
	message (as defined in Section 4.2). This mechanism token is		negotiation message (as defined in Section 4.2). This mechanism
	referred to as the optimistic token in this document. If the		token is referred to as the optimistic mechanism token in this
	selected mechanism matches the initiator's preferred mechanism, no		document. If the selected mechanism matches the initiator's
	additional round trips need to be incurred by using this protocol.		preferred mechanism, no additional round trips need be incurred by
	In addition, by using the optimistic token, the initiator can recover		using this protocol. In addition, using the optimistic mechanism
	from a non-fatal error in producing the first token before a		token allows the initiator to recover from non-fatal errors while
	mechanism can be selected. Implementations, however, MAY omit the		producing the first mechanism token before a mechanism can be
	optimistic token, to avoid the cost of generating it in cases where		selected. Implementations MAY omit the optimistic mechanism token to
	the initiator's preferred mechanism is not selected by the acceptor.		avoid the cost of generating it in cases where the initiator's
			preferred mechanism is not selected by the acceptor.
	SPNEGO uses the concepts developed in the GSS-API specification		SPNEGO relies the concepts developed in the GSS-API specification
	[RFC2743]. The negotiation data is encapsulated in context-level		[RFC2743]. The negotiation data is encapsulated in context-level
	tokens. Therefore, callers of the GSS-API do not need to be aware of		tokens. Therefore, callers of the GSS-API do not need to be aware of
	the existence of the negotiation tokens but only of the new		the existence of the negotiation tokens but only of the new
	pseudo-security mechanism. A failure in the negotiation phase causes		pseudo-security mechanism. A failure in the negotiation phase causes
	a major status code to be returned: GSS_S_BAD_MECH.		a major status code to be returned: GSS_S_BAD_MECH.
	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].
	3. Negotiation Protocol		3. Negotiation Protocol
	When the established mechanism context provides for integrity		When the established mechanism context provides integrity protection,
	protection, the mechanism negotiation can be protected. When		the mechanism negotiation can be protected. When acquiring
	acquiring negotiated security mechanism tokens, per-message integrity		negotiated security mechanism tokens, per-message integrity services
	services are always requested by the SPNEGO mechanism.		are always requested by the SPNEGO mechanism.
	When the established mechanism context supports per-message integrity		When the established mechanism context supports per-message integrity
	services, SPNEGO guarantees that the selected mechanism is mutually		services, SPNEGO guarantees that the selected mechanism is mutually
	preferred.		preferred.
	This section describes the negotiation process of this protocol.		This section describes the negotiation process of this protocol.
	3.1 Negotiation Description		3.1 Negotiation Description
	The first negotiation token sent by the initiator contains an ordered		The first negotiation token sent by the initiator contains an ordered
	list of mechanisms (in preference order, favorite choice first), and		list of mechanisms (in decreasing preference order, favorite
	optionally the initial security token for the preferred mechanism of		mechanism first), and optionally the initial mechanism token for the
	the initiator (i.e., the first in the list). The list of security		preferred mechanism of the initiator (i.e., the first in the list).
	mechanisms available for negotiation is based on the credentials		The list of security mechanisms available for negotiation is based on
	being used.		the credentials being used.
	The target then processes the token from the initiator. This will		The target then processes the token from the initiator. This will
	result in one of four possible states (as defined in Section 4.2.2):		result in one of four possible states (as defined in Section 4.2.2):
	accept_completed, accept_incomplete, reject, or request_mic. A		accept_completed, accept_incomplete, reject, or request_mic. A
	reject state will terminate the negotiation; an accept_completed		reject state will terminate the negotiation; an accept_completed
	state indicates that not only was the initiator-selected mechanism		state indicates that not only was the initiator-selected mechanism
	acceptable to the target, but that the initial token was sufficient		acceptable to the target, but also that the initial mechanism token
	to complete the authentication; an accept_incomplete state indicates		was sufficient to complete the authentication; an accept_incomplete
	that further message exchange is needed but the MIC token exchange as		state indicates that further message exchange is needed but the MIC
	described in Section 5 is OPITONAL; a request_mic state (this state		token exchange as described in Section 5 is OPTIONAL; a request_mic
	can only be present in the first reply message from the target)		state (this state can only be present in the first reply message from
	indicates the MIC token exchange is REQUIRED if per-message integrity		the target) indicates the MIC token exchange is REQUIRED if
	services are available.		per-message integrity services are available.
	Unless the preference order is specified by the application (see		Unless the preference order is specified by the application (see
	Appendix A), the policy by which the target chooses a mechanism is an		Appendix A), the policy by which the target chooses a mechanism is an
	implementation-specific local matter. In the absence of application		implementation-specific local matter. In the absence of an
	specified preference order or other policy, the target SHALL choose		application specified preference order or other policy, the target
	the first mechanism in the initiator proposed list for which it has		SHALL choose the first mechanism in the initiator proposed list for
	valid credentials.		which it has valid credentials.
	In case of a successful negotiation, the security mechanism in the		In case of a successful negotiation, the security mechanism in the
	first reply message represents the value suitable for the target, and		first reply message represents the value suitable for the target,
	picked up from the list offered by the initiator. A context level		picked up from the list offered by the initiator. A context level
	token for a reject state is OPTIONAL.		token for a reject state is OPTIONAL.
	Once a mechanism has been selected, the tokens specific to the		Once a mechanism has been selected, the tokens specific to the
	selected mechanism are carried within the negotiation tokens.		selected mechanism are carried within the negotiation tokens.
	Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the		Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
	mechanism list as seen by the target.		mechanism list received by the target.
	To avoid conflicts with the use of MIC tokens by SPNEGO,		To avoid conflicts with the use of MIC tokens by SPNEGO,
	partially-established contexts are not used for per-message calls:		partially-established contexts are not used for per-message calls:
	the prot_ready_state [RFC2743] will be false even if the underlying		the prot_ready_state [RFC2743] will be false even if the underlying
	mechanism would return true natively.		mechanism would return true natively.
	3.2 Negotiation Procedure		3.2 Negotiation Procedure
	The basic form of the procedure assumes that per-message integrity		The basic form of the procedure assumes that per-message integrity
	services are available on the established mechanism context, and it		services are available on the established mechanism context, and it
	is summarized as follows:		is summarized as follows:
	(a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,		(a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
	but requests (either explicitly, with the negotiation mechanism,		but requests that SPNEGO be used. SPNEGO can either be explicity
	or through accepting a default, when the default is this		requested or accepted as the default mechanism.
	negotiation mechanism) that SPNEGO is used.
	(b) The initiator GSS-API implementation emits a negotiation token		(b) The initiator GSS-API implementation emits a negotiation token
	containing a list of supported security mechanisms (possible just		containing a list of one or more security mechanisms that are
	one mechanism) for the credentials used for this context		available based on the credentials used for this context
	establishment, and optionally an initial security token for the		establishment, and optionally the initial mechanism token for the
	first mechanism from that list.		first mechanism in the list.
	(c) The GSS-API initiator application sends the token to the target		(c) The GSS-API initiator application sends the token to the target
	application. The GSS-API target application deposits the token		application. The GSS-API target application deposits the token by
	through invoking GSS_Accept_sec_context(). The acceptor will do		invoking GSS_Accept_sec_context(). The acceptor will do one of
	one of the following:		the following:
	(I) No proposed mechanism is acceptable, the negotiation SHALL be		(I) If none of the proposed mechanisms are acceptable, the
	terminated. GSS_Accept_sec_context indicates GSS_S_BAD_MECH.		negotiation SHALL be terminated. GSS_Accept_sec_context
	The acceptor MAY output a negotiation token containing a reject		indicates GSS_S_BAD_MECH. The acceptor MAY output a
	state.		negotiation token containing a reject state.
	(II) If either the initiator's preferred mechanism is not accepted		(II) If either the initiator's preferred mechanism is not accepted
	by the target, or this mechanism is accepted but it is not the		by the target or this mechanism is accepted but it is not the
	most preferred mechanism available for the acceptor (see		acceptor's most preferred mechanism (see Section 3.1 and
	Section 3.1 and Section 5), GSS_Accept_sec_context() indicates		Section 5), GSS_Accept_sec_context() indicates
	GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation		GSS_S_CONTINUE_NEEDED. The acceptor MUST output a negotiation
	token containing a request_mic state.		token containing a request_mic state.
	(III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE		(III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
	or GSS_S_CONTINUE_NEEDED, depending on if at least one		or GSS_S_CONTINUE_NEEDED depending on if at least one
	additional negotiation token from the initiator is needed to		additional negotiation token from the initiator is needed to
	establish this context. The acceptor outputs a negotiation		establish this context. The acceptor outputs a negotiation
	token containing an accept_complete or accept_incomplete state,		token containing an accept_complete or accept_incomplete state,
	respectively.		respectively.
	If the initiator's preferred mechanism is accepted, and an		If the initiator's preferred mechanism is accepted, and an
	optimistic mechanism token was included, this mechanism token MUST		optimistic mechanism token was included, this mechanism token MUST
	be deposited to the selected mechanism through invoking		be deposited to the selected mechanism by invoking
	GSS_Accept_sec_context() and if a response mechanism token is		GSS_Accept_sec_context() and if a response mechanism token is
	emitted, it MUST be included in the response negotiation token.		emitted, it MUST be included in the response negotiation token.
	Otherwise, the target will not emit a response mechanism token in		Otherwise, the target will not emit a response mechanism token in
	the first reply.		the first reply.
	(d) The GSS-API target application returns the negotiation token to		(d) The GSS-API target application returns the negotiation token to
	the initiator application. The GSS-API initiator application		the initiator application. The GSS-API initiator application
	deposits the token through invoking GSS_Init_sec_context(). The		deposits the token by invoking GSS_Init_sec_context(). The
	security context initialization is then continued according to the		security context initialization is then continued according to the
	standard GSS-API conventions for the selected mechanism, where the		standard GSS-API conventions for the selected mechanism, where the
	tokens of the selected mechanism are encapsulated until the		tokens of the selected mechanism are encapsulated until the
	GSS_S_COMPLETE is returned for both the initiator and the target		GSS_S_COMPLETE is returned for both the initiator and the target
	by the selected security mechanism.		by the selected security mechanism.
	(e) MIC tokens are then either skipped or exchanged according to		(e) MIC tokens are then either skipped or exchanged according to
	Section 5.		Section 5.
	Note that the *_req_flag input parameters for context establishment		Note that the *_req_flag input parameters for context establishment
	are relative to the selected mechanism, as are the *_state output		are relative to the selected mechanism, as are the *_state output
	parameters. i.e., these parameters are not applicable to the		parameters. i.e., these parameters are not applicable to the
	negotiation process per se.		negotiation process per se.
	On receipt of a negotiation token on the target side, a GSS-API		On receipt of a negotiation token on the target side, a GSS-API
	implementation that does not support negotiation would indicate the		implementation that does not support negotiation would indicate the
	GSS_S_BAD_MECH status as if a particular basic security mechanism had		GSS_S_BAD_MECH status as if a particular basic security mechanism had
	been requested but was not supported.		been requested and was not supported.
	When GSS_Acquire_cred is invoked with this SPNEGO mechanism as		When GSS_Acquire_cred is invoked with this negotiation mechanism in
	desired_mechs, an implementation-specific default credential is used		the desired_mechs, an implementation-specific default credential is
	to carry on the negotiation. A set of mechanisms as specified		used to carry on the negotiation. A set of mechanisms as specified
	locally by the system administrator is then available for		locally by the system administrator is then available for
	negotiation. If there is a desire for the caller to make its own		negotiation. If there is a desire for the caller to make its own
	choice, then an additional API has to be used (see Appendix A).		choice, then an additional API has to be used (see Appendix A).
	4. Token Definitions		4. Token Definitions
	The type definitions in this section assume an ASN.1 module		The type definitions in this section assume an ASN.1 module
	definition of the following form:		definition of the following form:
	SPNEGOASNOneSpec {		SPNEGOASNOneSpec {
	skipping to change at page 9, line 45		skipping to change at page 9, line 45
	4.2 Negotiation Tokens		4.2 Negotiation Tokens
	The syntax of the initial negotiation tokens follows the		The syntax of the initial negotiation tokens follows the
	initialContextToken syntax defined in Section 3.1 of [RFC2743]. The		initialContextToken syntax defined in Section 3.1 of [RFC2743]. The
	SPNEGO pseudo mechanism is identified by the Object Identifier		SPNEGO pseudo mechanism is identified by the Object Identifier
	specified in Section 1. Subsequent tokens are not encapsulated in		specified in Section 1. Subsequent tokens are not encapsulated in
	this GSS-API generic token framing.		this GSS-API generic token framing.
	This section specifies the syntax of the inner token for the initial		This section specifies the syntax of the inner token for the initial
	message, and the syntax of subsequent context establishment tokens.		message and the syntax of subsequent context establishment tokens.
	NegotiationToken ::= CHOICE {		NegotiationToken ::= CHOICE {
	negTokenInit [0] NegTokenInit,		negTokenInit [0] NegTokenInit,
	negTokenResp [1] negTokenResp		negTokenResp [1] negTokenResp
	}		}
	4.2.1 negTokenInit		4.2.1 negTokenInit
	NegTokenInit ::= SEQUENCE {		NegTokenInit ::= SEQUENCE {
	mechTypes [0] MechTypeList,		mechTypes [0] MechTypeList,
	skipping to change at page 10, line 32		skipping to change at page 10, line 32
	confFlag (5),		confFlag (5),
	integFlag (6)		integFlag (6)
	}		}
	This is the syntax for the inner token of the initial negotiation		This is the syntax for the inner token of the initial negotiation
	message.		message.
	mechTypes		mechTypes
	This field contains one or more security mechanisms available		This field contains one or more security mechanisms available
	for the initiator in preference order (favorite choice first).		for the initiator in decreasing preference order (favorite
			choice first).
	reqFlags		reqFlags
	This field, if present, contains the service options that are		This field, if present, contains the service options that are
	requested to establish the context. The context flags SHOULD		requested to establish the context. The context flags SHOULD
	be filled in from the req_flags parameter of		be filled in from the req_flags parameter of
	GSS_Init_sec_context(). This field SHALL NOT have impact on		GSS_Init_sec_context(). This field SHALL NOT have impact on
	the negotiation.		the negotiation.
	mechToken		mechToken
	This field, is present, contains the optimistic security		This field, if present, contains the optimistic mechanism
	mechanism token.		token.
	mechlistMIC		mechlistMIC
	This field, is present, contains a MIC token, which is computed		This field, if present, contains a MIC token for the mechanism
	according to Section 5, for the mechanism list in the initial		list in the initial negotiation message. This MIC token is
	negotiation message.		computed according to Section 5.
	4.2.2 negTokenResp		4.2.2 negTokenResp
	NegTokenResp ::= SEQUENCE {		NegTokenResp ::= SEQUENCE {
	negResult [0] ENUMERATED {		negResult [0] ENUMERATED {
	accept_completed (0),		accept_completed (0),
	accept_incomplete (1),		accept_incomplete (1),
	reject (2),		reject (2),
	request_mic (3)		request_mic (3)
	} OPTIONAL,		} OPTIONAL,
	skipping to change at page 12, line 11		skipping to change at page 12, line 19
	integrity services are available on the mechanism context to		integrity services are available on the mechanism context to
	be established. This value SHALL only be present in the		be established. This value SHALL only be present in the
	first reply from the target.		first reply from the target.
	This field is REQUIRED in the first reply from the target, and		This field is REQUIRED in the first reply from the target, and
	it is OPTIONAL thereafter.		it is OPTIONAL thereafter.
	supportedMech		supportedMech
	This field SHALL only be present in the first reply from the		This field SHALL only be present in the first reply from the
	target. It is a choice from the mechanism(s) offered by the		target. It MUST be one of the mechanism(s) offered by the
	initiator.		initiator.
	ResponseToken		ResponseToken
	The field, if present, contains tokens specific to the		This field, if present, contains tokens specific to the
	mechanism selected.		mechanism selected.
	mechlistMIC		mechlistMIC
	This field, is present, contains a MIC token, which is computed		This field, if present, contains a MIC token for the mechanism
	according to Section 5, for the mechanism list in the initial		list in the initial negotiation message. This MIC token is
	negotiation message.		computed according to Section 5.
	5. Processing of mechListMIC		5. Processing of mechListMIC
	If the mechanism selected by the negotiation does not support		If the mechanism selected by the negotiation does not support
	integrity protection, then no mechlistMIC token is used. Otherwise		integrity protection, then no mechlistMIC token is used.
	if the initiator's preferred mechanism is accepted and it is also the
	most preferred mechanism available for the acceptor (there is no		Otherwise if the accepted mechanism is the most preferred mechanism
	mechanism which, had it been present in the mechanism list, the		of both the initiator and the acceptor, then the MIC token exchange,
	acceptor would have preferred over the accepted mechanism), then the		as described later in this section, is OPTIONAL. A mechanism is the
	MIC token exchange, as described later in this section, is OPTIONAL.		acceptor's most preferred mechanism if there is no other mechanism
			which would have been preferred over the accepted mechanism if it had
			been present in the received mechanism list.
	In all other cases, MIC tokens MUST be exchanged after the mechanism		In all other cases, MIC tokens MUST be exchanged after the mechanism
	context is fully established.		context is fully established.
	It is assumed that per-message integrity services are available on		It is assumed that per-message integrity services are available on
	the established mechanism context in the following procedure for		the established mechanism context in the following procedure for
	processing MIC tokens of the initiator's mechanism list.		processing MIC tokens of the initiator's mechanism list.
	a) The mechlistMIC token (or simply the MIC token) is computed		a) The mechlistMIC token (or simply the MIC token) is computed by
	through invoking GSS_GetMIC(): the input context_handle is the		invoking GSS_GetMIC(): the input context_handle is the established
	established mechanism context, the input qop_req is 0, and the		mechanism context, the input qop_req is 0, and the input message
	input message is the mechTypes field in the initial negotiation		is the mechTypes field in the initial negotiation message (only
	message (only the DER encoding of type MechTypeList is included).		the DER encoding of the type MechTypeList is included).
	b) If the selected mechanism uses an even number of mechanism tokens		b) If the selected mechanism uses an even number of mechanism tokens
	(namely the acceptor sends the last mechanism token), the acceptor		(namely the acceptor sends the last mechanism token), the acceptor
	does the following when emitting the negotiation message		does the following when emitting the negotiation message
	containing the last mechanism token: if the MIC token exchange is		containing the last mechanism token: if the MIC token exchange is
	not required, GSS_Accept_sec_context() either indicates		not required, GSS_Accept_sec_context() either indicates
	GSS_S_COMPLETE and does not include a mechlistMIC token, or		GSS_S_COMPLETE and does not include a mechlistMIC token, or
	indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token		indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
	and an accept_incomplete state; if the MIC token exchange is		and an accept_incomplete state; if the MIC token exchange is
	required, GSS_Accept_sec_context() indicates		required, GSS_Accept_sec_context() indicates
	GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.		GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
	Acceptors who wish to be compatible with legacy Windows SPNEGO		Acceptors that wish to be compatible with legacy Windows SPNEGO
	implementations as described in Appendix B shall not generate a		implementations as described in Appendix B shall not generate a
	mechlistMIC token when the MIC token exchange is not required.		mechlistMIC token when the MIC token exchange is not required.
	The initiator then processes the last mechanism token, and does		The initiator then processes the last mechanism token, and does
	one of the following:		one of the following:
	(I) If a mechlistMIC token was included, and is correctly		(I) If a mechlistMIC token was included, and is correctly
	verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The		verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE. The
	output negotiation message contains a mechlistMIC token, and an		output negotiation message contains a mechlistMIC token, and an
	accept_complete state. The acceptor MUST then verify this		accept_complete state. The acceptor MUST then verify this
	mechlistMIC token.		mechlistMIC token.
	skipping to change at page 14, line 23		skipping to change at page 14, line 27
	c) In the case that the chosen mechanism uses an odd number of		c) In the case that the chosen mechanism uses an odd number of
	mechanism tokens (namely the initiator sends the last mechanism		mechanism tokens (namely the initiator sends the last mechanism
	token), the initiator does the following when emitting the		token), the initiator does the following when emitting the
	negotiation message containing the last mechanism token: if the		negotiation message containing the last mechanism token: if the
	negResult state was request_mic in the first reply from the		negResult state was request_mic in the first reply from the
	target, a mechlistMIC token MUST be included, otherwise the		target, a mechlistMIC token MUST be included, otherwise the
	mechlistMIC token is OPTIONAL. In the case that the optimistic		mechlistMIC token is OPTIONAL. In the case that the optimistic
	mechanism token is the only mechanism token for the initiator's		mechanism token is the only mechanism token for the initiator's
	preferred mechanism, the mechlistMIC token is OPTIONAL.		preferred mechanism, the mechlistMIC token is OPTIONAL.
	GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.		GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
	Initiators who wish to be compatible with legacy Windows SPNEGO		Initiators that wish to be compatible with legacy Windows SPNEGO
	implementations as described in Appendix B shall not generate a		implementations as described in Appendix B shall not generate a
	mechlistMIC token when the MIC token exchange is not required.		mechlistMIC token when the MIC token exchange is not required.
	The acceptor then processes the last mechanism token, and does one		The acceptor then processes the last mechanism token and does one
	of the following:		of the following:
	(I) If a mechlistMIC token was included, and is correctly		(I) If a mechlistMIC token was included and is correctly verified,
	verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.		GSS_Accept_sec_context() indicates GSS_S_COMPLETE. The output
	The output negotiation message contains a mechlistMIC token,		negotiation message contains a mechlistMIC token and an
	and an accept_complete state. The initiator MUST then verify		accept_complete state. The initiator MUST then verify this
	this mechlistMIC token.		mechlistMIC token.
	(II) If a mechlistMIC token was included but is incorrect, the		(II) If a mechlistMIC token was included but is incorrect, the
	negotiation SHALL be terminated. GSS_Accept_sec_context()		negotiation SHALL be terminated. GSS_Accept_sec_context()
	indicates GSS_S_DEFECTIVE_TOKEN.		indicates GSS_S_DEFECTIVE_TOKEN.
	(III) If no mechlistMIC token was included and the mechlistMIC		(III) If no mechlistMIC token was included but the mechlistMIC
	token exchange is not required, GSS_Accept_sec_context()		token exchange is not required, GSS_Accept_sec_context()
	indicates GSS_S_COMPLETE. The output negotiation message		indicates GSS_S_COMPLETE. The output negotiation message
	contains an accept_complete state.		contains an accept_complete state.
	(IV) In the case that the optimistic mechanism token is also the		(IV) In the case that the optimistic mechanism token is also the
	last mechanism token (when the initiator's preferred mechanism		last mechanism token (when the initiator's preferred mechanism
	is accepted by the target), and the target sends a request_mic		is accepted by the target) and the target sends a request_mic
	state, but the initiator did not send a mechlistMIC token, the		state but the initiator did not send a mechlistMIC token, the
	target then MUST include a mechlistMIC token in that first		target then MUST include a mechlistMIC token in that first
	reply. GSS_Accept_sec_context() indicates		reply. GSS_Accept_sec_context() indicates
	GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received		GSS_S_CONTINUE_NEEDED. The initiator MUST verify the received
	mechlistMIC token, and generate a mechlistMIC token to send		mechlistMIC token and generate a mechlistMIC token to send back
	back to the target, who SHALL in turn verify the returned		to the target. The target SHALL in turn verify the returned
	mechlistMIC token and complete the negotiation.		mechlistMIC token and complete the negotiation.
	(V) If no mechlistMIC token was included and the acceptor sent a		(V) If no mechlistMIC token was included and the acceptor sent a
	request_mic state in the first reply message (the exchange of		request_mic state in the first reply message (the exchange of
	MIC tokens is required), the negotiation SHALL be terminated.		MIC tokens is required), the negotiation SHALL be terminated.
	GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.		GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
	6. Extensibility		6. Extensibility
	Two mechanisms are provided by extensibility. First, the ASN.1		Two mechanisms are provided for extensibility. First, the ASN.1
	structures in this specification MAY be expanded by IETF standards		structures in this specification MAY be expanded by IETF standards
	action. Implementations receiving unknown fields MUST ignore these		action. Implementations receiving unknown fields MUST ignore these
	fields.		fields.
	Secondly, OIDs corresponding to a desired mechanism attribute may be		Secondly, OIDs corresponding to a desired mechanism attribute may be
	included in the set of preferred mechanisms by an initiator. The		included in the set of preferred mechanisms by an initiator. The
	acceptor can choose to honor this request by preferring mechanisms		acceptor can choose to honor this request by preferring mechanisms
	that have that attribute. Future work within the Kitten working		that have the included attributes. Future work within the Kitten
	group is expected to standardize common attributes that SPNEGO		working group is expected to standardize common attributes that
	mechanisms may wish to support. At this time it is sufficient to say		SPNEGO mechanisms may wish to support. At this time it is sufficient
	that initiators MAY include OIDs that do not correspond to mechanisms		to say that initiators MAY include OIDs that do not correspond to
	but instead correspond to desired mechanism attributes in their		mechanisms but instead correspond to desired mechanism attributes in
	requests. Such OIDs MAY influence the acceptor's choice of		their requests. Such OIDs MAY influence the acceptor's choice of
	mechanism. As discussed in Section 5, if there are mechanisms that		mechanism. As discussed in Section 5, if there are mechanisms that
	if present in the initiator's list of mechanisms might be preferred		if present in the initiator's list of mechanisms might be preferred
	by the acceptor to the initiator's preferred mechanism, the acceptor		by the acceptor to the initiator's preferred mechanism, the acceptor
	MUST demand the MIC token exchange. As a consequence, acceptors MUST		MUST demand the MIC token exchange. As a consequence, acceptors MUST
	demand the MIC token exchange if they support negotiation of		demand the MIC token exchange if they support negotiation of
	attributes not available in the initiator's preferred mechanism		attributes not available in the initiator's preferred mechanism
	regardless of whether the initiator actually requested these		regardless of whether the initiator actually requested these
	attributes.		attributes.
	7. Security Considerations		7. Security Considerations
	In order to produce the MIC token for the mechanism list, the		In order to produce the MIC token for the mechanism list, the
	mechanism must provide integrity protection. When the selected		mechanism must provide integrity protection. When the selected
	mechanism does not support integrity protection, then the negotiation		mechanism does not support integrity protection, the negotiation is
	is vulnerable: an active attacker can force it to use a security		vulnerable: an active attacker can force it to use a security
	mechanism that is not mutually preferred but is acceptable anyway to		mechanism that is not mutually preferred but is acceptable to the
	the target.		target.
	When per-message integrity services are available on the established		This protocol provides the following guarantees when per-message
	mechanism context, and there was an alteration of the mechanism list		integrity services are available on the established mechanism context
	by an adversary such that a common mechanism that is not mutually		and the mechanism list was altered by an adversary such that a
	preferred could be selected, this protocol provides the following		mechanism which is not mutually preferred could be selected:
	guarantees: if the last mechanism token is sent by the initiator,
	both peers shall fail; if the last mechanism token is sent by the		o if the last mechanism token is sent by the initiator, both peers
	acceptor, the acceptor shall not complete and the initiator at worst		shall fail;
	shall complete with its preferred mechanism being selected. The		o if the last mechanism token is sent by the acceptor, the acceptor
	negotiation may not be terminated if an alteration was made but it		shall not complete and the initiator at worst shall complete with
	had no material impact.		its preferred mechanism being selected.
			The negotiation may not be terminated if an alteration was made but
			it had no material impact.
	The protection of the negotiation depends on the strength of the		The protection of the negotiation depends on the strength of the
	integrity protection. In particular, the strength of SPNEGO is no		integrity protection. In particular, the strength of SPNEGO is no
	stronger than the integrity protection of the weakest mechanism		stronger than the integrity protection of the weakest mechanism
	acceptable to GSS-API peers.		acceptable to GSS-API peers.
	In all cases, the communicating peers are exposed to the denial of		In all cases, the communicating peers are exposed to the denial of
	service threat.		service threat.
	8. IANA Considerations		8. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	9. Acknowledgments		9. Acknowledgments
	The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,		The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
	Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments		Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
	and suggestions on earlier versions of this document.		and suggestions during development of this document.
	Luke Howard provided a prototype of this protocol in Heimdal, and		Luke Howard provided a prototype of this protocol in Heimdal and
	resolved several issues in the initial draft.		resolved several issues in the initial draft.
	Eric Baize and Denis Pinkas wrote the original SPNEGO specification		Eric Baize and Denis Pinkas wrote the original SPNEGO specification
	[RFC2478], of which some of the text has been retained in this		[RFC2478] of which some of the text has been retained in this
	document.		document.
	10 Normative References		10 Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API		[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
	Negotiation Mechanism", RFC 2478, December 1998.		Negotiation Mechanism", RFC 2478, December 1998.
	[RFC2743] 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.
	[X690] ASN.1 encoding rules: Specification of Basic Encoding Rules		[X690] ASN.1 encoding rules: Specification of Basic Encoding
	(BER), Canonical Encoding Rules (CER) and Distinguished		Rules (BER), Canonical Encoding Rules (CER) and
	Encoding Rules (DER), ITU-T Recommendation X.690 (1997) |		Distinguished Encoding Rules (DER), ITU-T Recommendation
	ISO/IEC International Standard 8825-1:1998.		X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
	Authors' Addresses		Authors' Addresses
	Larry Zhu		Larry Zhu
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	US		US
	EMail: lzhu@microsoft.com		EMail: lzhu@microsoft.com
	skipping to change at page 23, line 8		skipping to change at page 23, line 8
	available credentials).		available credentials).
	Note: The GSS_Indicate_mechs() function indicates the full set of		Note: The GSS_Indicate_mechs() function indicates the full set of
	mechanism types available on the local system. Since this call has		mechanism types available on the local system. Since this call has
	no input parameter, the returned set is not necessarily available for		no input parameter, the returned set is not necessarily available for
	all credentials.		all credentials.
	Appendix B. Changes since RFC2478		Appendix B. Changes since RFC2478
	SPNEGO implementations in Windows 2000/Windows XP/Windows Server		SPNEGO implementations in Windows 2000/Windows XP/Windows Server
	2003 have the following behavior: no mechlistMIC is produced, and		2003 have the following behavior: no mechlistMIC is produced and
	mechlistMIC is not processed if one is provided; if the initiator		mechlistMIC is not processed if one is provided; if the initiator
	sends the last mechanism token, the acceptor will send back a		sends the last mechanism token, the acceptor will send back a
	negotiation token with an accept_complete state and no mechlistMIC		negotiation token with an accept_complete state and no mechlistMIC
	token. In addition, the OID (1.2.840.48018.1.2.2) can be used to		token. In addition, the OID (1.2.840.48018.1.2.2) can be used to
	identify the GSS-API Kerberos Version 5 mechanism.		identify the GSS-API Kerberos Version 5 mechanism.
	The following changes have been made to be compatible with these		The following changes have been made to be compatible with these
	legacy implementations.		legacy implementations.
	* NegTokenTarg is changed to negTokenResp and it is the message		* NegTokenTarg is changed to negTokenResp and it is the message
	format for all subsequent negotiation tokens.		format for all subsequent negotiation tokens.
	* NegTokenInit is the message for the initial token and that		* NegTokenInit is the message for the initial negotiation message
	token only.		and that message only.
	* mechTypes in negTokenInit is not optional.		* mechTypes in negTokenInit is not optional.
	* Two MIC tokens are exchanged, one in each direction.		* Two MIC tokens are exchanged, one in each direction.
	* If the selected mechanism is also the most preferred mechanism		* If the selected mechanism is also the most preferred mechanism
	for both peers, it is safe to omit the MIC tokens.		for both peers, it is safe to omit the MIC tokens.
	If at least one of the two peers implements the pseudo mechanism		If at least one of the two peers implements the pseudo mechanism
	in this document, the negotiation is protected.		in this document, the negotiation is protected.
	The following changes are to address the problems in RFC 2478.		The following changes are to address the problems in RFC 2478.
	* reqFlags is not protected therefore it should not impact the		* reqFlags is not protected therefore it should not impact the
	negotiation.		negotiation.
	* DER encoding is required.		* DER encoding is required.
	* GSS_GetMIC() input is clarified.		* GSS_GetMIC() input is clarified.
	* Per-message integrity services are requested for the negotiated		* Per-message integrity services are requested for the negotiated
	mechanism.		mechanism.
			An implementation that conforms to this specification will not
			interoperate with a strict 2748 implementation. Even if the new
			implementation always sends a mechlistMIC token, it will still fail
			to interoperate. If it is a server, it will fail because it requests
			a mechlistMIC token using an option that older implementations simply
			do not support. Clients will tend to fail as well.
			As an alternative to the approach chosen in this specification, we
			could have documented a correct behavior that is fully backward
			compatible with RFC 2478 and included an appendix on how to
			interoperate with existing incorrect implementations of RFC 2478.
			As a practical matter, the SPNEGO implementers within the IETF have
			valued interoperability with the Microsoft implementations. We were
			unable to choose to maintain reasonable security guarantees, maintain
			interoperability with the Microsoft implementations and maintain
			interoperability with correct implementations of RFC 2478. The
			working group was not aware of any RFC 2478 implementations. Even if
			there are RFC 2478 implementations, it is unlikely that they will
			interoperate because of a critical flaw in the description of the
			encoding of the mechanism list in RFC 2478.
			With the approach taken in this specification, we get security
			between new implementations all the time while maintaining
			interoperability with the implementations we have within the IETF
			community. The working group believes that this justifies breaking
			compatibility with a correct implementation of RFC 2478.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/