--- 1/draft-ietf-kitten-2478bis-03.txt 2006-02-05 00:06:37.000000000 +0100 +++ 2/draft-ietf-kitten-2478bis-04.txt 2006-02-05 00:06:37.000000000 +0100 @@ -1,21 +1,21 @@ NETWORK WORKING GROUP L. Zhu Internet-Draft P. Leach Obsoletes: 2478 (if approved) K. Jaganathan -Expires: June 14, 2005 Microsoft Corporation +Expires: June 15, 2005 Microsoft Corporation W. Ingersoll Sun Microsystems - December 14, 2004 + December 15, 2004 The Simple and Protected GSS-API Negotiation Mechanism - draft-ietf-kitten-2478bis-03 + draft-ietf-kitten-2478bis-04 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each 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 become aware will be disclosed, in accordance with RFC 3668. @@ -28,21 +28,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The Internet Society (2004). Abstract This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. @@ -188,22 +188,22 @@ terminate the negotiation; an accept_completed state indicates that not only was the initiator-selected mechanism acceptable to the target, but also that the optimistic mechanism token was sufficient to complete the authentication; an accept_incomplete state indicates that further message exchange is needed but the MIC token exchange as described in Section 5 is OPTIONAL; a request_mic state (this state can only be present in the first reply message from the target) indicates the MIC token exchange is REQUIRED if per-message integrity services are available. - Unless the preference order is specified by the application (see - Appendix A), the policy by which the target chooses a mechanism is an + Unless the preference order is specified by the application, the + policy by which the target chooses a mechanism is an implementation-specific local matter. In the absence of an application specified preference order or other policy, the target SHALL choose the first mechanism in the initiator proposed list for which it has valid credentials. In case of a successful negotiation, the security mechanism in the first reply message represents the value suitable for the target, chosen from the list offered by the initiator. In case of an unsuccessful negotiation, the reject state is returned @@ -276,43 +276,45 @@ GSS_Accept_sec_context() and if a response mechanism token is emitted, it MUST be included in the response negotiation token. Otherwise, the target will not emit a response mechanism token in the first reply. (d) The GSS-API target application returns the negotiation token to the initiator application. The GSS-API initiator application deposits the token by invoking GSS_Init_sec_context(). The security context initialization is then continued according to the standard GSS-API conventions for the selected mechanism, where the - tokens of the selected mechanism are encapsulated until the - GSS_S_COMPLETE is returned for both the initiator and the target - by the selected security mechanism. + tokens of the selected mechanism are encapsulated in negotiation + messages (see Section 4) until the GSS_S_COMPLETE is returned for + both the initiator and the target by the selected security + mechanism. (e) MIC tokens are then either skipped or exchanged according to Section 5. Note that the *_req_flag input parameters for context establishment are relative to the selected mechanism, as are the *_state output parameters. i.e., these parameters are not applicable to the negotiation process per se. On receipt of a negotiation token on the target side, a GSS-API implementation that does not support negotiation would indicate the GSS_S_BAD_MECH status as if a particular basic security mechanism had been requested and was not supported. - When GSS_Acquire_cred is invoked with this negotiation mechanism in - the desired_mechs, an implementation-specific default credential is - used to carry on the negotiation. A set of mechanisms as specified - locally 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 API has to be used (see Appendix A). + When a GSS-API credential is acquired for the SPNEGO mechanism the + implementation SHOULD produce a credential element for the SPNEGO + mechanism which internally contains GSS-API credential elements for + all mechanisms for which the principal has credentials available, + except for any mechanisms which are not to be negotiated, either as + per implementation-, site- or application-specific policy. See + Appendix A for interfaces for expressing application policy. 4. Token Definitions The type definitions in this section assume an ASN.1 module definition of the following form: SPNEGOASNOneSpec { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanism(5) snego (2) modules(4) spec2(2) } DEFINITIONS EXPLICIT TAGS ::= BEGIN @@ -336,36 +338,38 @@ -- OID represents each security mechanism as suggested by -- [RFC2743] MechTypeList ::= SEQUENCE OF MechType 4.2 Negotiation Tokens The syntax of the initial negotiation tokens follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. The SPNEGO pseudo mechanism is identified by the Object Identifier - specified in Section 1. Subsequent tokens are not encapsulated in - this GSS-API generic token framing. + specified in Section 1. Subsequent tokens MUST NOT be encapsulated + in this GSS-API generic token framing. This section specifies the syntax of the inner token for the initial message and the syntax of subsequent context establishment tokens. NegotiationToken ::= CHOICE { negTokenInit [0] NegTokenInit, negTokenResp [1] negTokenResp } 4.2.1 negTokenInit NegTokenInit ::= SEQUENCE { mechTypes [0] MechTypeList, reqFlags [1] ContextFlags OPTIONAL, + -- maintained from RFC 2478 for backward compatibility, + -- RECOMMENDED to be left out mechToken [2] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL, ... } ContextFlags ::= BIT STRING { delegFlag (0), mutualFlag (1), replayFlag (2), sequenceFlag (3), anonFlag (4), @@ -441,21 +445,23 @@ request_mic The sender indicates that the exchange of MIC tokens, as described in Section 5, will be REQUIRED if per-message integrity services are available on the mechanism context to be established. This value SHALL only be present in the first reply from the target. 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 This field SHALL only be present in the first reply from the target. It MUST be one of the mechanism(s) offered by the initiator. ResponseToken This field, if present, contains tokens specific to the @@ -580,26 +586,25 @@ action. Implementations receiving unknown fields MUST ignore these fields. Secondly, OIDs corresponding to a desired mechanism attribute (i.e., mechanism variants) may be included in the set of preferred mechanisms by an initiator. The acceptor can choose to honor this request by preferring mechanisms that have the included attributes. Future work within the Kitten working group is expected to standardize common attributes that SPNEGO mechanisms may wish to support. At this time it is sufficient to say that initiators MAY - include OIDs that do not correspond to mechanisms but instead - correspond to desired mechanism attributes in their requests. Such - OIDs MAY influence the acceptor's choice of mechanism. As discussed - in Section 5, if there are mechanisms that if present in the - initiator's list of mechanisms might be preferred by the acceptor to - the initiator's preferred mechanism, the acceptor MUST demand the MIC + include OIDs that do not correspond to mechanisms. Such OIDs MAY + influence the acceptor's choice of mechanism. As discussed in + Section 5, if there are mechanisms that if present in the initiator's + list of mechanisms might be preferred by the acceptor to the + initiator's preferred mechanism, the acceptor MUST demand the MIC token exchange. As a consequence, acceptors MUST demand the MIC token exchange if they support negotiation of attributes not available in the initiator's preferred mechanism regardless of whether the initiator actually requested these attributes. 7. Security Considerations In order to produce the MIC token for the mechanism list, the mechanism must provide integrity protection. When the selected mechanism does not support integrity protection, the negotiation is