draft-ietf-kitten-2478bis-03.txt		draft-ietf-kitten-2478bis-04.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: June 14, 2005 Microsoft Corporation		Expires: June 15, 2005 Microsoft Corporation
	W. Ingersoll		W. Ingersoll
	Sun Microsystems		Sun Microsystems
	December 14, 2004		December 15, 2004
	The Simple and Protected GSS-API Negotiation Mechanism		The Simple and Protected GSS-API Negotiation Mechanism
	draft-ietf-kitten-2478bis-03		draft-ietf-kitten-2478bis-04
	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 39		skipping to change at page 1, line 39
	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 June 14, 2005.		This Internet-Draft will expire on June 15, 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 6, line 41		skipping to change at page 6, line 41
	terminate the negotiation; an accept_completed state indicates that		terminate the negotiation; an accept_completed state indicates that
	not only was the initiator-selected mechanism acceptable to the		not only was the initiator-selected mechanism acceptable to the
	target, but also that the optimistic mechanism token was sufficient		target, but also that the optimistic mechanism token was sufficient
	to complete the authentication; an accept_incomplete state indicates		to complete the authentication; an accept_incomplete state indicates
	that further message exchange is needed but the MIC token exchange as		that further message exchange is needed but the MIC token exchange as
	described in Section 5 is OPTIONAL; a request_mic state (this state		described in Section 5 is OPTIONAL; a request_mic state (this state
	can only be present in the first reply message from the target)		can only be present in the first reply message from the target)
	indicates the MIC token exchange is REQUIRED if per-message integrity		indicates the MIC token exchange is REQUIRED if per-message integrity
	services are available.		services are available.
	Unless the preference order is specified by the application (see		Unless the preference order is specified by the application, the
	Appendix A), the policy by which the target chooses a mechanism is an		policy by which the target chooses a mechanism is an
	implementation-specific local matter. In the absence of an		implementation-specific local matter. In the absence of an
	application specified preference order or other policy, the target		application specified preference order or other policy, the target
	SHALL choose the first mechanism in the initiator proposed list for		SHALL choose the first mechanism in the initiator proposed list for
	which it has 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,		first reply message represents the value suitable for the target,
	chosen from the list offered by the initiator.		chosen from the list offered by the initiator.
	In case of an unsuccessful negotiation, the reject state is returned		In case of an unsuccessful negotiation, the reject state is returned
	skipping to change at page 8, line 33		skipping to change at page 8, line 33
	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 by 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 in negotiation
	GSS_S_COMPLETE is returned for both the initiator and the target		messages (see Section 4) until the GSS_S_COMPLETE is returned for
	by the selected security mechanism.		both the initiator and the target 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 and was not supported.		been requested and was not supported.
	When GSS_Acquire_cred is invoked with this negotiation mechanism in		When a GSS-API credential is acquired for the SPNEGO mechanism the
	the desired_mechs, an implementation-specific default credential is		implementation SHOULD produce a credential element for the SPNEGO
	used to carry on the negotiation. A set of mechanisms as specified		mechanism which internally contains GSS-API credential elements for
	locally by the system administrator is then available for		all mechanisms for which the principal has credentials available,
	negotiation. If there is a desire for the caller to make its own		except for any mechanisms which are not to be negotiated, either as
	choice, then an additional API has to be used (see Appendix A).		per implementation-, site- or application-specific policy. See
			Appendix A for interfaces for expressing application policy.
	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 {
	iso(1) identified-organization(3) dod(6) internet(1)		iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanism(5) snego (2) modules(4) spec2(2)		security(5) mechanism(5) snego (2) modules(4) spec2(2)
	} DEFINITIONS EXPLICIT TAGS ::= BEGIN		} DEFINITIONS EXPLICIT TAGS ::= BEGIN
	skipping to change at page 10, line 41		skipping to change at page 10, line 41
	-- OID represents each security mechanism as suggested by		-- OID represents each security mechanism as suggested by
	-- [RFC2743]		-- [RFC2743]
	MechTypeList ::= SEQUENCE OF MechType		MechTypeList ::= SEQUENCE OF MechType
	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 MUST NOT be encapsulated
	this GSS-API generic token framing.		in 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,
	reqFlags [1] ContextFlags OPTIONAL,		reqFlags [1] ContextFlags OPTIONAL,
			-- maintained from RFC 2478 for backward compatibility,
			-- RECOMMENDED to be left out
	mechToken [2] OCTET STRING OPTIONAL,		mechToken [2] OCTET STRING OPTIONAL,
	mechListMIC [3] 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),
	skipping to change at page 13, line 14		skipping to change at page 13, line 14
	request_mic		request_mic
	The sender indicates that the exchange of MIC tokens, as		The sender indicates that the exchange of MIC tokens, as
	described in Section 5, will be REQUIRED if per-message		described in Section 5, will be REQUIRED if per-message
	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. When negState is absent the actual
			state should be inferred from the state of the negotiated
			mechanism context.
	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 MUST be one of the mechanism(s) offered by the		target. It MUST be one of the mechanism(s) offered by the
	initiator.		initiator.
	ResponseToken		ResponseToken
	This field, if present, contains tokens specific to the		This field, if present, contains tokens specific to the
	skipping to change at page 17, line 19		skipping to change at page 17, line 19
	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 (i.e.,		Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
	mechanism variants) may be included in the set of preferred		mechanism variants) may be included in the set of preferred
	mechanisms by an initiator. The acceptor can choose to honor this		mechanisms by an initiator. The acceptor can choose to honor this
	request by preferring mechanisms that have the included attributes.		request by preferring mechanisms that have the included attributes.
	Future work within the Kitten working group is expected to		Future work within the Kitten working group is expected to
	standardize common attributes that SPNEGO mechanisms may wish to		standardize common attributes that SPNEGO mechanisms may wish to
	support. At this time it is sufficient to say that initiators MAY		support. At this time it is sufficient to say that initiators MAY
	include OIDs that do not correspond to mechanisms but instead		include OIDs that do not correspond to mechanisms. Such OIDs MAY
	correspond to desired mechanism attributes in their requests. Such		influence the acceptor's choice of mechanism. As discussed in
	OIDs MAY influence the acceptor's choice of mechanism. As discussed		Section 5, if there are mechanisms that if present in the initiator's
	in Section 5, if there are mechanisms that if present in the		list of mechanisms might be preferred by the acceptor to the
	initiator's list of mechanisms might be preferred by the acceptor to		initiator's preferred mechanism, the acceptor MUST demand the MIC
	the initiator's preferred mechanism, the acceptor MUST demand the MIC
	token exchange. As a consequence, acceptors MUST demand the MIC		token exchange. As a consequence, acceptors MUST demand the MIC
	token exchange if they support negotiation of attributes not		token exchange if they support negotiation of attributes not
	available in the initiator's preferred mechanism regardless of		available in the initiator's preferred mechanism regardless of
	whether the initiator actually requested these attributes.		whether the initiator actually requested these 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, the negotiation is		mechanism does not support integrity protection, the negotiation is
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/