< draft-ietf-cat-snego-07.txt		draft-ietf-cat-snego-08.txt >
	Internet-Draft Eric Baize, Denis Pinkas		Internet-Draft Eric Baize, Denis Pinkas
	IETF Common Authentication Technology WG Bull		IETF Common Authentication Technology WG Bull
	<draft-ietf-cat-snego-07.txt> 18 November 1997		<draft-ietf-cat-snego-08.txt> 4 March 1998
	The Simple and Protected GSS-API Negotiation Mechanism		The Simple and Protected GSS-API Negotiation Mechanism
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	2. ABSTRACT		2. ABSTRACT
	This draft document specifies a Security Negotiation Mechanism for the		This draft document specifies a Security Negotiation Mechanism for the
	Generic Security Service Application Program Interface (GSS-API) which		Generic Security Service Application Program Interface (GSS-API) which
	is described in [1].		is described in [1].
	The GSS-API provides a generic interface which can be layered atop		The GSS-API provides a generic interface which can be layered atop
	different security mechanisms such that if communicating peers acquire		different security mechanisms such that if communicating peers acquire
	GSS-API credentials for the same security mechanism, then a security		GSS-API credentials for the same security mechanism, then a security
	7context may be established between them (subject to policy). However,		context may be established between them (subject to policy). However,
	GSS-API doesn't prescribe the method by which GSS-API peers can		GSS-API doesn't prescribe the method by which GSS-API peers can
	establish whether they have a common security mechanism.		establish whether they have a common security mechanism.
	The Simple and Protected GSS-API Negotiation Mechanism defined here		The Simple and Protected GSS-API Negotiation Mechanism defined here
	is a pseudo-security mechanism, represented by the object identifier		is a pseudo-security mechanism, represented by the object identifier
	iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which		iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
	enables GSS-API peers to determine in-band whether their credentials		enables GSS-API peers to determine in-band whether their credentials
	share common GSS-API security mechanism(s), and if so, to invoke		share common GSS-API security mechanism(s), and if so, to invoke
	normal security context establishment for a selected common security		normal security context establishment for a selected common security
	mechanism. This is most useful for applications that are based on		mechanism. This is most useful for applications that are based on
	GSS-API implementations which support multiple security mechanisms.		GSS-API implementations which support multiple security mechanisms.
	This allows to negotiate different security mechanisms, different		This allows to negotiate different security mechanisms, different
	options within a given security mechanism (such as different		options within a given security mechanism or different options from
	cryptographic algorithms due to policy or legislative constraints)		several security mechanisms.
	or different options from several security mechanisms.
	Once the common security mechanism is identified, the mechanism may		Once the common security mechanism is identified, the security
	then negotiate mechanism-specific options during its context		mechanism may also negotiate mechanism-specific options during its
	establishment. This will be inside the mechanism tokens, and		context establishment. This will be inside the mechanism tokens, and
	invisible to the SPNEGO protocol.		invisible to the SPNEGO protocol.
	The simple and protected GSS-API mechanism negotiation is based on the		The simple and protected GSS-API mechanism negotiation is based on the
	following negotiation model : the initiator proposes one security		following negotiation model : the initiator proposes one security
	mechanism or an ordered list of security mechanisms, the target either		mechanism or an ordered list of security mechanisms, the target either
	accepts the proposed security mechanism, or chooses one from an		accepts the proposed security mechanism, or chooses one from an
	offered set, or rejects the proposed value(s). The target then informs		offered set, or rejects the proposed value(s). The target then informs
	the initiator of its choice.		the initiator of its choice.
	In its basic form this protocol requires an extra-round trip. Network		In its basic form this protocol requires an extra-round trip. Network
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 30 ¶
	initial security token for the desired mechanism of the initiator		initial security token for the desired mechanism of the initiator
	(i.e. the first of the list).		(i.e. the first of the list).
	The first negotiation token sent by the target contains the result of		The first negotiation token sent by the target contains the result of
	the negotiation (accept_completed, accept_incomplete or reject) and,		the negotiation (accept_completed, accept_incomplete or reject) and,
	in case of accept, the agreed security mechanism. It may also include		in case of accept, the agreed security mechanism. It may also include
	the response to the initial security token from the initiator, when		the response to the initial security token from the initiator, when
	the first proposed mechanism of the initiator has been selected. When		the first proposed mechanism of the initiator has been selected. When
	the first mechanism is acceptable to the target,it should respond to		the first mechanism is acceptable to the target,it should respond to
	the initial security token for the desired mechanism of the initiator		the initial security token for the desired mechanism of the initiator
	when it is present. However, if this is not possible, they can simply		when it is present. However, if this is not possible, the target can
	ignore it and omit the preferredToken from the reply. Implementations		simply ignore it and omit the responseToken from the first reply.
	that can piggyback the initial token will be rewarded by faster
	connection setup.		Implementations that can piggyback the initial token will be rewarded
			by faster connection setup.
	In case of a successful negotiation, the security mechanism represents		In case of a successful negotiation, the security mechanism represents
	the value suitable for the target, and picked up from the list offered		the value suitable for the target, and picked up from the list offered
	by the initiator. The policy by which the target chooses a mechanism		by the initiator. The policy by which the target chooses a mechanism
	is an implementation-specific local matter. In the absence of other		is an implementation-specific local matter. In the absence of other
	policy, the target should chose the first mechanism in the list for		policy, the target should chose the first mechanism in the list for
	which valid credentials are available.		which valid credentials are available.
			Once a mechanism has been selected, the tokens specific to the
			selected mechanism are carried within the negotiation tokens (in the
			mechToken for the initiator and in the responseToken for the target).
	3.2. Negotiation procedure		3.2. Negotiation procedure
	The negotiation procedure is summarised as follows:		The negotiation procedure is summarised as follows:
	(a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but		(a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
	requests (either explicitly, with the negotiation mechanism, or		requests (either explicitly, with the negotiation mechanism, or
	through accepting a default, when the default is the negotiation		through accepting a default, when the default is the negotiation
	mechanism) that the Simple and Protected GSS-API Negotiation Mechanism		mechanism) that the Simple and Protected GSS-API Negotiation Mechanism
	be used;		be used;
	(b) the initiator GSS-API implementation emits a negotiation token		(b) the initiator GSS-API implementation emits a negotiation token
	containing the set of supported security mechanism for the credentials		containing a list of supported security mechanisms for the credentials
	used for this context establishment, and optionally the initial		used for this context establishment, and optionally an initial
	security token for the preferred mechanism, and indicates		security token for the first mechanism from that list (i.e. the
	GSS_S_CONTINUE_NEEDED status;		preferred mechanism), and indicates GSS_S_CONTINUE_NEEDED status;
	(c) The GSS-API initiator sends the token to the target application;		(c) The GSS-API initiator sends the token to the target application;
	(d) The GSS-API target deposits the token through invoking		(d) The GSS-API target deposits the token through invoking
	GSS_Accept_sec_context. The target GSS-API implementation emits a		GSS_Accept_sec_context. The target GSS-API implementation emits a
	negotiation token containing which if any of the proposed mechanisms		negotiation token containing which if any of the proposed mechanisms
	it supports (or has selected).		it supports (or has selected).
	If the preferred mechanism selected by the target matches the preferred		If the mechanism selected by the target matches the preferred
	mechanism identified by the initiator and the initiator provides a		mechanism identified by the initiator and the initiator provides a
	preferredToken, the negotiation token response may contain also the		mechToken, the negotiation token response may contain also an initial
	initial security token from that mechanism.		security token from that mechanism.
	If the preferred mechanism is accepted, GSS_Accept_sec_context()		If the preferred mechanism is accepted, GSS_Accept_sec_context()
	indicates GSS_S_COMPLETE when unilateral or mutual authentication has		indicates GSS_S_COMPLETE when unilateral or mutual authentication has
	been performed and involves a single token in either direction.		been performed and involves a single token in either direction.
			If a proposed mechanism other than the preferred mechanism is
			accepted, the negotiation token response may contain also an initial
			security token from that mechanism (e.g. to transmit a certificate).
	If a proposed mechanism other than the preferred mechanism is accepted,		If a proposed mechanism other than the preferred mechanism is accepted,
	or the preferred mechanism is accepted but involves multiple exchanges		or the preferred mechanism is accepted but involves multiple exchanges
	(e.g. challenge-response authentication), then GSS_Accept_sec_context()		(e.g. challenge-response authentication), then GSS_Accept_sec_context()
	indicates GSS_S_CONTINUE_NEEDED status.		indicates GSS_S_CONTINUE_NEEDED status.
	If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()		If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
	indicates GSS_S_BAD_MECH status. The security context initialisation		indicates GSS_S_BAD_MECH status. The security context initialisation
	has failed.		has failed.
	(e) The GSS-API target returns the token to the initiator application;		(e) The GSS-API target returns the token to the initiator application;
	(f) The GSS-API initiator deposits the token through invoking		(f) The GSS-API initiator deposits the token through invoking
	GSS_Init_sec_context.		GSS_Init_sec_context.
	GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED,		GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED,
	GSS_S_COMPLETE or GSS_S_BAD_MECH status.		GSS_S_COMPLETE or GSS_S_BAD_MECH status.
	The GSS_S_BAD_MECH status is returned when the negotiation token		The GSS_S_BAD_MECH status is returned when the negotiation token
	carries a reject result or when the negotiation token carries an		carries a reject result or when the negotiation token carries an
	accept result and the mechanism selected by the target is not		accept result and the mechanism selected by the target is not
	included in the initial list sent by the initiator or the		included in the initial list sent by the initiator.
	selected mechanism supports a MIC token but the MIC computed over
	the list of mechanisms sent by the initiator is missing or		The GSS_S_BAD_SIG status is returned when the selected mechanism
	incorrect. If the negotiation token carries a reject result, the		supports a MIC token but the MIC computed over the list of
			mechanisms sent by the initiator is missing or incorrect.
			If the negotiation token carries a reject result, the
	context establishment is impossible. For example, a rejection		context establishment is impossible. For example, a rejection
	will occur if the target doesn't support the initiator's proposed		will occur if the target doesn't support the initiator's proposed
	mechanism type(s). Upon failure of the		mechanism type(s). Upon failure of the mechanism negotiation
	mechanism negotiation procedure, the mech_type output parameter		procedure, the mech_type output parameter value is the
	value is the negotiation mechanism type.		negotiation mechanism type.
	The GSS_S_CONTINUE_NEEDED status is returned when the negotiation		The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
	token carries an accept result and further tokens must be		token carries an accept result and further tokens must be
	transferred in order to complete context establishment for the		transferred in order to complete context establishment for the
	selected mechanism. In that case GSS_Init_sec_context() returns		selected mechanism. In that case GSS_Init_sec_context() returns
	an initial context token as output_token (with the selected		an initial context token as output_token (with the selected
	mechanism's context token encapsulated within that output_token).		mechanism's context token encapsulated within that output_token).
	The initiator then sends the output_token to the target. The		The initiator then sends the output_token to the target. The
	security context initialisation is then continued according to		security context initialisation is then continued according to
	the standard GSS-API conventions for the selected mechanism,		the standard GSS-API conventions for the selected mechanism,
	where the tokens of the selected mechanism are encapsulated until		where the tokens of the selected mechanism are encapsulated until
	the GSS_S_COMPLETE is returned for both the initiator and the		the GSS_S_COMPLETE is returned for both the initiator and the
	target. When GSS_S_CONTINUE_NEEDED is returned, the mech_type		target. When GSS_S_CONTINUE_NEEDED is returned, the mech_type
	output parameter is not yet valid.		output parameter is not yet valid.
	When GSS_S_COMPLETE is returned, the mech_type output parameter		When GSS_S_COMPLETE is returned, the mech_type output parameter
	indicates the selected mechanism. When the final negotiation token		indicates the selected mechanism. When the final negotiation token
	skipping to change at page 5, line 45 ¶		skipping to change at page 6, line 4 ¶
	to carry on the negotiation. A set of mechanisms as specified locally		to carry on the negotiation. A set of mechanisms as specified locally
	by the system administrator is then available for negotiation. If there		by the system administrator is then available for negotiation. If there
	is a desire for the caller to make its own choice, then an additional		is a desire for the caller to make its own choice, then an additional
	API has to be used (see Appendix A).		API has to be used (see Appendix A).
	4. DATA ELEMENTS		4. DATA ELEMENTS
	4.1. Mechanism Type		4.1. Mechanism Type
	MechType::= OBJECT IDENTIFIER		MechType::= OBJECT IDENTIFIER
	mechType		mechType
	Each security mechanism is as defined in [1].		Each security mechanism is as defined in [1].
	4.2. Negotiation Tokens		4.2. Negotiation Tokens
	The syntax of the negotiation tokens follows the InitialContextToken		The syntax of the negotiation tokens follows the InitialContextToken
	syntax defined in [1]. The security mechanism of the initial		syntax defined in [1]. The security mechanism of the initial
	negotiation token is identified by the Object Identifier		negotiation token is identified by the Object Identifier
	iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).		iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
	4.2.1. Syntax		4.2.1. Syntax
	This section specifies the syntax of the corresponding		This section specifies the syntax of the corresponding
	"innerContextToken" field for the first token and subsequent		"innerContextToken" field for the first token and subsequent
	negotiation tokens.		negotiation tokens. During the mechanism negociation,
			the "innerContextToken" field contains the ASN.1 structure
			"NegociationToken" given below, encoded using the BER/DER encoding
			conventions.
	NegotiationToken ::= CHOICE {		NegotiationToken ::= CHOICE {
	negTokenInit [0] NegTokenInit,		negTokenInit [0] NegTokenInit,
	negTokenTarg [1] NegTokenTarg }		negTokenTarg [1] NegTokenTarg }
	MechType ::= OBJECT IDENTIFIER
	MechTypeList ::= SEQUENCE OF MechType		MechTypeList ::= SEQUENCE OF MechType
	NegTokenInit ::= SEQUENCE {		NegTokenInit ::= SEQUENCE {
	mechTypes [0] MechTypeList OPTIONAL		mechTypes [0] MechTypeList OPTIONAL,
	reqFlags [1] ContextFlags OPTIONAL,		reqFlags [1] ContextFlags OPTIONAL,
	preferredToken [2] OCTET STRING OPTIONAL		mechToken [2] OCTET STRING OPTIONAL,
			mechListMIC [3] OCTET STRING OPTIONAL
	}		}
	ContextFlags ::= BIT STRING {		ContextFlags ::= BIT STRING {
	delegFlag (0),		delegFlag (0),
	mutualFlag (1),		mutualFlag (1),
	replayFlag (2),		replayFlag (2),
	sequenceFlag (3),		sequenceFlag (3),
	anonFlag (4),		anonFlag (4),
	confFlag (5),		confFlag (5),
	> integFlag (6)		integFlag (6)
	}		}
	negTokenInit		negTokenInit
	Negotiation token sent by the initiator to the target, which		Negotiation token sent by the initiator to the target, which
	contains, for the first token sent, one or more security		contains, for the first token sent, one or more security
	mechanisms supported by the initiator and the service options		mechanisms supported by the initiator (as indicated in the field
	(reqFlags) that are requested to establish the context. The		mechTypes) and the service options (reqFlags) that are requested
	preferredToken is an optional field of the first token sent that		to establish the context. The context flags should be filled in
			from the req_flags parameter of init_sec_context().
			The mechToken field is optional for the first token sent that
	all target implementations would not have to support. However		all target implementations would not have to support. However
	for those targets that do support piggybacking the initial		for those targets that do support piggybacking the initial
	preferredToken, an optimistic negotiation response is possible.		mechToken, an optimistic negotiation response is possible.
	The context flags should be filled in from the req_flags parameter		Otherwise the mechToken is used to carry the tokens specific to
	of init_sec_context()		the mechanism selected.
			The mechListMIC is an optional field. In the case that the chosen
			mechanism supports integrity, the initiator may optionally include
			a mechListMIC which is the result of a GetMIC of the MechTypes in
			the initial NegTokenInit and return GSS_S_COMPLETE.
			When the chosen mechanism uses an odd number of messages, the
			final mechanism token will be sent from the initiator to the
			acceptor. In this case, there is a tradeoff between using the
			optimal number of messages, or using an additional message from
			the acceptor to the initiator in order to give the initiator
			assurance that no modification of the initiator's mechanism list
			occurred. The implementation can choose which tradeoff to make
			(see section 4.2.2 for further details for the processing of that
			field).
	NegTokenTarg ::= SEQUENCE {		NegTokenTarg ::= SEQUENCE {
	negResult [0] ENUMERATED {		negResult [0] ENUMERATED {
	accept_completed (0),		accept_completed (0),
	accept_incomplete (1),		accept_incomplete (1),
	reject (2) } OPTIONAL		reject (2) } OPTIONAL,
	supportedMech [1] MechType OPTIONAL		supportedMech [1] MechType OPTIONAL,
	responseToken [2] OCTET STRING OPTIONAL		responseToken [2] OCTET STRING OPTIONAL,
	mechListMIC [3] OCTET STRING OPTIONAL		mechListMIC [3] OCTET STRING OPTIONAL
	}		}
	negTokenTarg		negTokenTarg
	Negotiation token returned by the target to the initiator which		Negotiation token returned by the target to the initiator which
	contains, for the first token returned, a global negotiation		contains, for the first token returned, a global negotiation
	result and the security mechanism selected (if any).		result and the security mechanism selected (if any).
	The result accept_completed indicates that a context
	has been successfully established using the preferredToken that		negResult
	was initially sent by the initiator, while the result		The result accept_completed indicates that a context has been
	accept_incomplete indicates that additional token exchanges are		successfully established, while the result accept_incomplete
	needed.		indicates that additional token exchanges are needed.
	Note: For the case where (a) a single-token context setup		Note: For the case where (a) a single-token context setup
	is used and (b) the preferred mechanism does not support		is used and (b) the preferred mechanism does not support
	the integrity facility which would cause a mechListMIC to be		the integrity facility which would cause a mechListMIC to be
	generated and enclosed, this feature allows to make a		generated and enclosed, this feature allows to make a
	difference between a preferredToken sent by the initiator		difference between a mechToken sent by the initiator
	but not processed by the target (accept_incomplete) and		but not processed by the target (accept_incomplete) and
	a preferredToken sent by the initiator and processed by		a mechToken sent by the initiator and processed by
	the target (accept_completed).		the target (accept_completed).
	For those targets that support piggybacking the initial		For those targets that support piggybacking the initial
	preferredToken, an optimistic negotiation response is possible		mechToken, an optimistic negotiation response is possible
	and includes in that case a responseToken which may continue		and includes in that case a responseToken which may continue
	the authentication exchange (e.g. when mutual authentication has		the authentication exchange (e.g. when mutual authentication has
	been requested or when unilateral authentication requires several		been requested or when unilateral authentication requires several
	round trips). Otherwise the responseToken is used to carry the		round trips). Otherwise the responseToken is used to carry the
	tokens specific to the mechanism selected.		tokens specific to the mechanism selected.
	For subsequent tokens (if any) returned by the target, negResult,		For subsequent tokens (if any) returned by the target, negResult,
	and supportedMech are not present.		and supportedMech are not present.
	For the last token returned by the target, the mechListMIC, when		For the last token returned by the target, the mechListMIC, when
	skipping to change at page 7, line 40 ¶		skipping to change at page 8, line 14 ¶
	For subsequent tokens (if any) returned by the target, negResult,		For subsequent tokens (if any) returned by the target, negResult,
	and supportedMech are not present.		and supportedMech are not present.
	For the last token returned by the target, the mechListMIC, when		For the last token returned by the target, the mechListMIC, when
	present, is a MIC computed over the MechTypes using the selected		present, is a MIC computed over the MechTypes using the selected
	mechanism.		mechanism.
	negResult		negResult
	Result of the negotiation exchange, specified by the target.		Result of the negotiation exchange, specified by the target.
	This can be either :		This can be either :
	accept_completed		accept_completed
	The target accepts the preferred security mechanism,		The target accepts the preferred security mechanism,
	and the context is established for the target or,		and the context is established for the target or,
	accept_incomplete		accept_incomplete
	The target accepts one of the proposed security		The target accepts one of the proposed security
	mechanisms and further exchanges are necessary, or,		mechanisms and further exchanges are necessary, or,
	reject		reject
	The target rejects all the proposed security		The target rejects all the proposed security
	mechanisms.		mechanisms.
	supportedMech		supportedMech
	This field has to be present when negResult is "accept_completed"		This field has to be present when negResult is "accept_completed"
	or "accept_incomplete". It is a choice from the mechanisms offered		or "accept_incomplete". It is a choice from the mechanisms offered
	by the initiator.		by the initiator.
	responseToken		responseToken
	This field may be used either to transmit the response to the		This field may be used either to transmit the response to the
	preferredToken when sent by the initiator and when the first		mechToken when sent by the initiator and when the first
	mechanism from the list has been selected by the target or		mechanism from the list has been selected by the target or
	to carry the tokens specific to the selected security mechanism.		to carry the tokens specific to the selected security mechanism.
	mechListMIC		mechListMIC
	If the selected mechanism is capable of integrity protection,		If the selected mechanism is capable of integrity protection,
	this field must be present in the last message of the negotiation,		this field must be present in the last message of the negotiation,
	(i.e., when the underlying mechanism returns a non-empty token		(i.e., when the underlying mechanism returns a non-empty token
	and a major status of GSS_S_COMPLETE); it contains the result of a		and a major status of GSS_S_COMPLETE); it contains the result of a
	GetMIC of the MechTypes field in the initial NegTokenInit.		GetMIC of the MechTypes field in the initial NegTokenInit.
	It allows to verify that the list initially sent by the initiator		It allows to verify that the list initially sent by the initiator
	has been received unmodified by the target.		has been received unmodified by the target.
	4.2.2. Processing of mechListMIC.		4.2.2. Processing of mechListMIC.
	When the mechanism selected by the negotiation supports integrity		If the mechanism selected by the negotiation does not support
	protection as a service, the mechListMIC must be used and validated.		integrity, then no mechListMIC is included, otherwise a
			mechListMIC must be used and validated as indicated below.
	In particular, the target that sends the last context establishment		If the mechanism supports integrity and uses an even number of
	token must also include the result of a gss_get_mic() of the		messages, then the target must compute a MIC as described above,
	mechTypeList sent by the initiator in the first token; in addition,		and send this in the final NegTokenTarg along with the final
	the initiator that receives the last token must require that the		mechToken. The initiator when receiving the last token must
	mechListMIC field be present and valid. In the absence of a valid		require that the mechListMIC field be present and valid. In the
	mechListMIC, the negotiation must fail as if the last context		absence of a valid mechListMIC, the negotiation must fail as if
	establishment token was invalid.		the last context establishment token was invalid.
			In the case that the chosen mechanism supports integrity and uses
			an odd number of messages, the final mechanism token will be sent
			from the initiator to the target. In this case, there is a
			tradeoff between using the optimal number of messages, or using an
			additional message from the target to the initiator in order to
			give the initiator assurance that no modification of the
			initiator's mechanism list occurred. The implementation can choose
			which tradeoff to make.
			When generating the final NegTokenInit message, the NegTokenInit
			may optionally include a mechListMIC which is the result of a
			GetMIC of the MechTypes in the initial NegTokenInit and return
			GSS_S_COMPLETE. The target must check the presence of the MIC
			computed over the mechList sent in the initial NegTokenInit.
			Three cases may then be considered:
			1) If the mechListMIC is present and correct the context is
			established by the target.
			2) If the mechList is present but corrupted, then the context
			establishment must fail.
			3) If the mechListMIC is not included in the final
			NegTokenInit, then GSS_S_CONTINUE_NEEDED must be returned
			to the target. The MIC must then be included in the
			NegTokenTarg as described above, and the NegTokenTarg must
			be sent back to the initiator, which must verify that the
			mechListMIC field is present and valid.
			Note : If the MIC was originally sent by the initiator, but
			thenafter deleted by an attacker, the target will send
			back a token according to the description above, but
			the initiator will be unable to process that returned
			token and the context establishment must then fail.
	5. EXAMPLES : SECURITY MECHANISM NEGOTIATION		5. EXAMPLES : SECURITY MECHANISM NEGOTIATION
	Here are some examples of security mechanism negotiation between an		Here are some examples of security mechanism negotiation between an
	initiator (I) and a target (T).		initiator (I) and a target (T).
	5.1. Initial steps		5.1. Initial steps
	(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).		(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
	skipping to change at page 9, line 5 ¶		skipping to change at page 10, line 16 ¶
	major_status = GSS_S_CONTINUE_NEEDED		major_status = GSS_S_CONTINUE_NEEDED
	output_token = negTokenInit		output_token = negTokenInit
	The negotiation token (negTokenInit) contains two security mechanisms		The negotiation token (negTokenInit) contains two security mechanisms
	with :		with :
	mechType = GSS-MECH1 or		mechType = GSS-MECH1 or
	mechType = GSS-MECH2		mechType = GSS-MECH2
	(I) sends to (T) the negotiation token.		(I) sends to (T) the negotiation token.
	5.2 Successful negotiation steps		5.2 Successful negotiation steps
	(T) supports GSS-MECH2		(T) supports GSS-MECH2
	(T) receives the negotiation token (negTokenInit) from (I)		(T) receives the negotiation token (negTokenInit) from (I)
	(T) invokes GSS_Accept_sec_context() with :		(T) invokes GSS_Accept_sec_context() with :
	Input		Input
	input_token = negTokenInit		input_token = negTokenInit
	Output		Output
	major_status = GSS_S_CONTINUE_NEEDED		major_status = GSS_S_CONTINUE_NEEDED
	skipping to change at page 10, line 32 ¶		skipping to change at page 11, line 43 ¶
	Output		Output
	major_status = GSS_S_CONTINUE_NEEDED		major_status = GSS_S_CONTINUE_NEEDED
	output_token = negTokenInit		output_token = negTokenInit
	The negotiation token (negTokenInit) contains two security mechanisms		The negotiation token (negTokenInit) contains two security mechanisms
	with :		with :
	mechType = GSS-MECH1 or		mechType = GSS-MECH1 or
	mechType = GSS-MECH2		mechType = GSS-MECH2
	preferredToken = output_token from GSS_Init_sec_context		mechToken = output_token from GSS_Init_sec_context
	( first mechType) as described in [1]		( first mechType) as described in [1]
	(I) sends to (T) the negotiation token.		(I) sends to (T) the negotiation token.
	(T) supports GSS-MECH1.		(T) supports GSS-MECH1.
	(T) receives the negotiation token (negTokenInit) from (I)		(T) receives the negotiation token (negTokenInit) from (I)
	(T) invokes GSS_Accept_sec_context() with :		(T) invokes GSS_Accept_sec_context() with :
	Input		Input
	input_token = negTokenInit		input_token = negTokenInit
	Output		Output
	major_status = GSS_S_CONTINUE_NEEDED		major_status = GSS_S_CONTINUE_NEEDED
	output_token = negTokenTarg		output_token = negTokenTarg
	The negotiation token (negTokenTarg) contains :		The negotiation token (negTokenTarg) contains :
	negResult = accept (the negotiation result)		negResult = accept (the negotiation result)
	supportedMech : mechType = GSS-MECH1		supportedMech : mechType = GSS-MECH1
	preferredToken = output_token from
	GSS_Accept_sec_context(preferredToken )		mechToken = output_token from
			GSS_Accept_sec_context(mechToken )
	(T) returns the negotiation token (negTokenTarg) to (I)		(T) returns the negotiation token (negTokenTarg) to (I)
	(I) invokes GSS_Init_sec_context() with :		(I) invokes GSS_Init_sec_context() with :
	Input		Input
	input_token = negTokenTarg		input_token = negTokenTarg
	Output		Output
	major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed		major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed
	output_token = ContextToken (initial or subsequent context token		output_token = ContextToken (initial or subsequent context token
	skipping to change at page 11, line 31 ¶		skipping to change at page 12, line 44 ¶
	Acknowledgments are due to Piers McMahon and Tom Parker of ICL,		Acknowledgments are due to Piers McMahon and Tom Parker of ICL,
	Stephen Farrell of SSE, Doug Rosenthal of EINet, John Linn of		Stephen Farrell of SSE, Doug Rosenthal of EINet, John Linn of
	RSA Laboratories, and Marc Horowitz of Cygnus Solutions for reviewing		RSA Laboratories, and Marc Horowitz of Cygnus Solutions for reviewing
	earlier versions of this document and for providing useful inputs.		earlier versions of this document and for providing useful inputs.
	Acknowledgments are also due to Peter Brundrett of Microsoft for		Acknowledgments are also due to Peter Brundrett of Microsoft for
	his proposal for an optimistic negotiation, and for Bill Sommerfeld		his proposal for an optimistic negotiation, and for Bill Sommerfeld
	of Hewlett-Packard for his proposal for protecting the negotiation.		of Hewlett-Packard for his proposal for protecting the negotiation.
	7. SECURITY CONSIDERATIONS		7. SECURITY CONSIDERATIONS
	The purpose of the generic simple GSS-API mechanism negotiation
	mechanism is to enable peers to agree on the value for a security
	mechanism for initialising security services.
	When the mechanism selected by the target from the list supplied by		When the mechanism selected by the target from the list supplied by
	the initiator supports integrity protection, then the negotiation is		the initiator supports integrity protection, then the negotiation is
	protected.		protected.
	When one of the mechanisms proposed by the initiator does not support		When one of the mechanisms proposed by the initiator does not support
	integrity protection, then the negotiation is exposed to all threats		integrity protection, then the negotiation is exposed to all threats
	a non secured service is exposed. In particular, an active attacker		a non secured service is exposed. In particular, an active attacker
	can force to use a security mechanism which is not the common		can force to use a security mechanism which is not the common
	preferred one (when multiple security mechanisms are shared between		preferred one (when multiple security mechanisms are shared between
	peers) but which is acceptable anyway to the target.		peers) but which is acceptable anyway to the target.
	skipping to change at page 13, line 36 ¶		skipping to change at page 14, line 36 ¶
	[1] Linn, J., "Generic Security Service Application Program		[1] Linn, J., "Generic Security Service Application Program
	Interface", RFC 2078, OpenVision, January 1997. Available on		Interface", RFC 2078, OpenVision, January 1997. Available on
	ftp://ds.internic.net/rfc/rfc2078.txt		ftp://ds.internic.net/rfc/rfc2078.txt
	[2] Standard ECMA-206, "Association Context Management including		[2] Standard ECMA-206, "Association Context Management including
	Security Context Management", December 1993. Available on		Security Context Management", December 1993. Available on
	http://www.ecma.ch		http://www.ecma.ch
	AUTHORS'S ADDRESSES		AUTHORS'S ADDRESSES
	Eric Baize Internet email: E.Baize@ma02.bull.com		Eric Baize Internet email: E.Baize@bull.com
	Bull HN - MA02/211S Phone: +1 508 294 61 37		Bull HN - MA02/211S Phone: +1 508 294 61 37
	Technology Park Fax: +1 508 294 61 09		Technology Park Fax: +1 508 294 61 09
	Billerica, MA 01821 - USA		Billerica, MA 01821 - USA
	Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr		Denis Pinkas Internet email: D.Pinkas@bull.net
	Bull Phone: +33 1 30 80 34 87		Bull Phone: +33 1 30 80 34 87
	Rue Jean-Jaures Fax: +33 1 30 80 33 21		Rue Jean-Jaures Fax: +33 1 30 80 33 21
	BP 68		BP 68
	78340 Les Clayes-sous-Bois - FRANCE		78340 Les Clayes-sous-Bois - FRANCE
End of changes. 42 change blocks.
	70 lines changed or deleted		140 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/