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/