xref: /macosx-10.10.1/Heimdal-398.1.2/doc/standardisation/draft-zhu-spnego-2478bis-00.txt

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                             K. Jaganathan
Obsoletes: 2478 (if approved)                                    R. Ward
Expires: April 18, 2005                            Microsoft Corporation
                                                        October 18, 2004



         The Simple and Protected GSS-API Negotiation Mechanism
                      draft-zhu-spnego-2478bis-00


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.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   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 April 18, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This document specifies a security negotiation mechanism for the
   Generic Security Service Application Program Interface (GSS-API)
   which is described in RFC 2743.


   This mechanism allows negotiating and choosing one security mechanism
   from a common set of security mechanisms shared by GSS-API peers.




Zhu, et al.              Expires April 18, 2005                 [Page 1]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



   Once the common security mechanism is identified, the security
   mechanism MAY also negotiate mechanism-specific options during its
   context establishment, but that will be inside the mechanism tokens,
   and invisible to this protocol.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Negotiation Model  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  5
     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  6
   4.  Data Elements  . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1   Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 11
     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 11
       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 12
       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
   A.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18





























Zhu, et al.              Expires April 18, 2005                 [Page 2]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



1.  Introduction


   The GSS-API [RFC2743] provides a generic interface which can be
   layered atop different security mechanisms such that if communicating
   peers acquire GSS-API credentials for the same security mechanism,
   then a security context MAY be established between them (subject to
   policy).  However, GSS-API doesn't prescribe the method by which
   GSS-API peers can establish whether they have a common security
   mechanism.


   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
   defined here 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 enables GSS-API peers to determine in-band
   whether their credentials share common GSS-API security mechanism(s),
   and if so, to invoke normal security context establishment for a
   selected common security mechanism.  This is most useful for
   applications that are based on GSS-API implementations which support
   multiple security mechanisms.


   The simple and protected GSS-API mechanism negotiation is based on
   the following negotiation model: the initiator proposes one security
   mechanism or a list of security mechanisms in its preference order
   (favorite choice first), the acceptor (the target) either accepts the
   proposed security mechanism, or chooses one from the offered list, or
   rejects the proposed value(s).  The target then informs the initiator
   of its choice.


   In order to avoid an extra round trip, the initial security token of
   the preferred mechanism for the initiator SHOULD be embedded in the
   initial negotiation token (as defined in Section 4.2).  If the target
   preferred mechanism matches the initiator's preferred mechanism, no
   additional round trips may be incurred by using the negotiation
   protocol.


   The negotiation is protected and all the underlying mechanisms
   offered by the initiator MUST be capable of integrity protection.


   The Simple and Protected GSS-API Negotiation Mechanism uses the
   concepts developed in the GSS-API specification [RFC2743].  The
   negotiation data is encapsulated in context-level 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 pseudo-security mechanism.
   A failure in the negotiation phase causes a major status code to be
   returned: GSS_S_BAD_MECH.







Zhu, et al.              Expires April 18, 2005                 [Page 3]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



2.  Conventions Used in This Document


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].















































Zhu, et al.              Expires April 18, 2005                 [Page 4]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



3.  Negotiation Model


3.1  Negotiation Description


   Each OID represents one GSS-API mechanism or one variant of it.


   The first negotiation token sent by the initiator contains an ordered
   list of mechanisms (in preference order, favorite choice first), and
   OPTIONALLY the initial security token for the preferred mechanism of
   the initiator (i.e.  the first of the list).


   The target then processes the token from the initiator.  This will
   result in one of three possible states (as defined in Section 4.2.2):
   accept_completed, accept_incomplete, or reject.  A reject state will
   terminate the negotiation.  An accept_completed state indicates that
   not only was the initiator-selected mechanism acceptable to the
   target, but that the initial token was sufficient to complete the
   authentication.  An accept_incomplete state indicates that the target
   has selected a different mechanism or the preferred mechanism is
   acceptable, but this mechanism requires at least one additional
   message to complete the authentication.  The target MAY produce a
   context level token for a reject state.


   The first negotiation token sent by the acceptor contains the result
   of the negotiation (accept_completed, accept_incomplete or reject)
   and, in case of accept, the agreed security mechanism.  It MUST also
   include the response mechanism token to the initial mechanism token
   from the initiator, when the first proposed mechanism of the
   initiator has been selected and an initial mechanism token was
   provided by the initiator.  However, if the initiator's preferred
   mechanism is not possible, the target will not emit a response
   mechanism token in the first reply.


   The policy by which the target chooses a mechanism is an
   implementation-specific local matter.  In the absence of other
   policy, the target MUST choose the first mechanism in the list for
   which valid credentials are available.


   The first negotiation token is the negTokenInit message and all
   subsequent negotiation tokens are the negTokenResp message, as
   defined in Section 4.2.


   The use of partially-established contexts (as indicated by the
   prot_ready_state in [RFC2743]), either for this mechanism or
   mechanisms negotiated using this mechanism, is prohibited.







Zhu, et al.              Expires April 18, 2005                 [Page 5]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



3.2  Negotiation Procedure


   The negotiation procedure is summarized as follows:


   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
      but requests (either explicitly, with the negotiation mechanism,
      or through accepting a default, when the default is the
      negotiation mechanism) that the Simple and Protected GSS-API
      Negotiation Mechanism is used;


   (b) The initiator GSS-API implementation emits a negotiation token
      containing a list of supported security mechanisms for the
      credentials used for this context establishment, and OPTIONALLY an
      initial security token for the first mechanism from that list
      (i.e.  the preferred mechanism), and indicates
      GSS_S_CONTINUE_NEEDED status;


   (c) The GSS-API initiator application sends the token to the target
      application;


   (d) The GSS-API target application deposits the token through
      invoking GSS_Accept_sec_context.  The target GSS-API application
      will do one of the following:


      (I) If the initiator's preferred mechanism is accepted by the
         target, an initial token is included in the first token from
         the initiator, no further mechanism token from the initiator is
         needed for the chosen mechanism to establish the security
         context, (e.g.  when the authentication mechanism is unilateral
         or mutual authentication has been performed and involves a
         single token in either direction), and the initiator has not
         sent a MIC token (the output token of the GSS_GetMIC() call
         [RFC2743], the input to GSS_GetMIC() is the OTCET STRING field
         representing the MechTypes in the initial NegTokenInit token),
         of the mechanism list, the acceptor will do one of the
         following:


         1) If the initiator's preferred mechanism is accepted and there
            is no policy on the target such that a different mechanism
            other than the initiator's preferred mechanism could have
            been selected given a different list of mechanisms,
            GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE and it
            MUST produce a negotiation token with the accept_completed
            state, and with no MIC of the mechanism list.  This is
            referred in this document as the Safe to Omit MIC (SOMIC)
            rule number 1.  The resulting negotiation token MUST include
            the security token if one is returned by the selected
            mechanism;




Zhu, et al.              Expires April 18, 2005                 [Page 6]


         2) If the initiator's preferred mechanism is accepted and there
            is policy exists on the target such that a different
            mechanism other than the initiator's preferred mechanism
            could have been selected given a different list of
            mechanisms, GSS_Accept_sec_context() MUST indicate
            GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and
            a MIC MUST be generated by the target.  This MIC is to be
            verified by the initiator and the result will be sent back
            to the acceptor.  This is referred in this document as the
            Safe to Omit MIC (SOMIC) rule number 2.  The resulting
            negotiation token MUST include the security token if one is
            returned by the selected mechanism.


         3) If there is a MIC token and it is correct,
            GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE with
            no output token; If there is an incorrect MIC token,
            GSS_Accept_sec_context() must indicate GSS_S_BAD_MIC status,
            OPTIONALLY returning a negotiation token with the reject
            state.


      (II) If the initiator's preferred mechanism is accepted, and an
         initial token from this mechanism is sent by the initiator, but
         a failure is returned by the chosen mechanism,
         GSS_Accept_sec_context() MUST report the failure and the
         mech_type output parameter indicates the selected mechanism.
         The target MUST produce a negotiation token with the reject
         state if the selected mechanism returns a response token (e.g.
         a KRB_ERROR when the Kerberos Version 5 GSS-API mechanism is
         chosen [GSSAPICFX]);


      (III) If the initiator's preferred mechanism is accepted, and an
         initial token from this mechanism is sent by the initiator, but
         at last one more initiator token need to be transferred to
         establish the context, GSS_Accept_sec_context() MUST indicate
         GSS_S_CONTINUE_NEEDED status, returning a negotiation token
         with the accept_incomplete state, the response mechanism token,
         and no MIC token.


      (IV) If the initiator's preferred mechanism is accepted, but no
         initial token from this mechanism is sent by the initiator,
         GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
         status, returning a negotiation token with the
         accept_incomplete state, the selected mechanism, no response
         mechanism token or MIC token.


      (V) If a proposed mechanism is accepted, and it is not the
         initiator's preferred mechanism, GSS_Accept_sec_context() MUST
         indicate GSS_S_CONTINUE_NEEDED status, returning a negotiation
         token with the accept_incomplete state, the selected mechanism,
         no response mechanism token or MIC token.  The negotiation will




Zhu, et al.              Expires April 18, 2005                 [Page 7]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



         be the agreed security mechanism if the negotiation is
         successful.


   (e) The GSS-API target application returns the negotiation token to
      the initiator application;


   (f) The GSS-API initiator application deposits the token through
      invoking GSS_Init_sec_context().  The initiator will do one of the
      following:


      (I) When the negotiation token carries an accept_completed result,
         the initiator MUST do one of the following:


         1) If the selected mechanism is the initiator's preferred
            mechanism, the initiator SHALL NOT reject the negotiation if
            no MIC token is present.  This is referred in this document
            as the Safe to Omit MIC ("SOMIC") rule number 3.  The
            initiator MUST deposit the security token if one is
            included, GSS_Init_sec_context() MUST indicate
            GSS_S_BAD_MECH status if the context is not established
            after this GSS_Init_sec_context() call.  If a MIC token is
            present, the initiator MUST verify it and a GSS_S_BAD_MIC
            must be returned if the MIC is incorrect;


         2) If the selected mechanism is not the initiator's preferred
            mechanism, and there is no or an incorrect MIC token,
            GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC status.
            This is referred in this document as the Safe to Omit MIC
            ("SOMIC") rule number 4.


      (II) When the negotiation token carries a reject result without a
         response security token, GSS_Init_sec_context() MUST indicate
         GSS_S_BAD_MECH status;


      (III) When the negotiation token carries a reject result with a
         response security token, the initiator MUST deposit the
         security token, and GSS_Init_sec_context() MUST indicate a
         failure status reported by the underlying mechanism, and the
         output mech_type indicates the selected mechanism;


      (IV) When the negotiation token carries an accept_incomplete
         result and further mechanism tokens from the acceptor must be
         transferred in order to complete context establishment,
         GSS_Init_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
         status, returning an output token with the accept_incomplete,
         and the selected mechanism's context level token;






Zhu, et al.              Expires April 18, 2005                 [Page 8]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



      (V) When the negotiation token carries an accept_incomplete
         result, no further mechanism token need to be transferred from
         the acceptor to complete the context establishment, the
         initiator MUST do one of the following:


         1) If a MIC token was included, the initiator MUST verify it
            and GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC if
            the MIC is incorrect; GSS_Init_sec_context() MUST indicate
            GSS_S_COMPLETE and produce a negotiation with the
            accept_completed state if the MIC is correct.  This is
            referred in this document as the Safe to Omit MIC ("SOMIC")
            rule number 5;


         2) If no MIC token was present, GSS_Init_sec_context() MUST
            indicate GSS_S_BAD_MIC statue, This is referred in this
            document as the Safe to Omit MIC ("SOMIC") rule number 6.


   (g) The initiator application then sends the output_token to the
      target if one is returned.  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.  When no further mechanism token is
      needed to be transferred and the context for the chosen mechanism
      is established, the initiator and the acceptor will need to either
      apply the "SOMIC" rules above and skip MIC generation and
      verification, or generate and verify the MIC token to protect the
      negotiation.


   (h) When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
      parameter is not yet valid.  When GSS_S_COMPLETE is returned, the
      mech_type output parameter indicates the selected mechanism.


   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 but was not supported.


   When GSS_Acquire_cred is invoked with the negotiation mechanism as
   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




Zhu, et al.              Expires April 18, 2005                 [Page 9]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



   choice, then an additional API has to be used as defined in [PRTSTK].



















































Zhu, et al.              Expires April 18, 2005                [Page 10]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



4.  Data Elements


   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)
      } DEFINITIONS EXPLICIT TAGS ::= BEGIN


      -- rest of definitions here


      END


   This specifies that the tagging context for the module will be
   explicit and non-automatic.


   The encoding of SPNEGO protocol messages shall obey the Distinguished
   Encoding Rules (DER) of ASN.1 as described in [X690].


4.1  Mechanism Type


           MechType ::= OBJECT IDENTIFIER
             -- OID represents each security mechanism as suggested by
             -- [RFC2743]



4.2  Negotiation Tokens


   The syntax of the initial negotiation tokens follows the
   InitialContextToken syntax defined in [RFC2743].  The security
   mechanism of the initial negotiation token is identified by the
   Object Identifier in Section 1.  All subsequent tokens are not
   encapsulated in the above generic token framing.


   This section specifies the syntax of initial and subsequent context
   level tokens.


           NegotiationToken ::= CHOICE {
               negTokenInit    [0] NegTokenInit,
               negTokenResp    [1] negTokenResp
           }


           MechTypeList ::= SEQUENCE OF MechType








Zhu, et al.              Expires April 18, 2005                [Page 11]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



4.2.1  negTokenInit


           NegTokenInit ::= SEQUENCE {
               mechTypes       [0] MechTypeList,
               reqFlags        [1] ContextFlags  OPTIONAL,
               mechToken       [2] OCTET STRING  OPTIONAL,
               mechListMIC     [3] OCTET STRING  OPTIONAL,
               ...
           }


           ContextFlags ::= BIT STRING {
               delegFlag       (0),
               mutualFlag      (1),
               replayFlag      (2),
               sequenceFlag    (3),
               anonFlag        (4),
               confFlag        (5),
               integFlag       (6)
           }


   This is the message for the initial negotiation token.


   mechTypes


         This field contains one or more security mechanisms in the
         preference order (favorite choice first) supported by the
         initiator (as indicated in the field mechTypes).


   reqFlags


         This field, if present, contains the service options that are
         requested to establish the context.  The context flags SHOULD
         be filled in from the req_flags parameter of
         GSS_Init_sec_context().  This field SHALL NOT influence the
         outcome of the negotiation.


   mechToken


         This field, is present, contains an optimistic negotiation
         response.


   mechListMIC


         This field, if present, contains the result of a GSS_GetMIC()
         [RFC2743] of the MechTypes field in the initial NegTokenInit
         token.  It allows verifying that the list initially sent by the
         initiator has been received unmodified by the target.





Zhu, et al.              Expires April 18, 2005                [Page 12]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



4.2.2  negTokenResp


               NegTokenResp ::= SEQUENCE {
                   negResult       [0] ENUMERATED {
                       accept_completed    (0),
                       accept_incomplete   (1),
                       reject              (2)
                       },
                   supportedMech   [1] MechType      OPTIONAL,
                   responseToken   [2] OCTET STRING  OPTIONAL,
                   mechListMIC     [3] OCTET STRING  OPTIONAL,
                       -- used only by the acceptor
                   ...
               }


   This is the message for all the subsequent tokens.


   negResult


         Result of the negotiation exchange, specified by the target.
         This can be:


         accept_completed
            A security mechanism is selected, and the context is
            established for the sender;


         accept_incomplete
            Further exchanges are necessary;


         reject
            The sender reject the proposed security mechanism(s).


         accept_completed indicates that a context has been successfully
         established, while the result accept_incomplete indicates that
         additional token exchanges are needed.


         For those targets that support piggybacking the initial
         mechToken, an optimistic negotiation response is possible and
         includes in that case a responseToken which MAY continue the
         authentication exchange (e.g.  when mutual authentication has
         been requested or when unilateral authentication requires
         several round trips).  Otherwise the responseToken is used to
         carry the tokens specific to the mechanism selected.


         The mechListMIC, when present, is a MIC computed over the
         MechTypes using the mechanism list field in the initial token
         (encoded in DER).





Zhu, et al.              Expires April 18, 2005                [Page 13]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



   supportedMech


         This field is present and only present in the first
         negTokenResp token.  It is a choice from the mechanisms offered
         by the initiator.


   responseToken


         This field, if present, contains the security token of the
         selected mechanism.


   mechListMIC


         This field, if present, contains the result of a GSS_GetMIC()
         [RFC2743] of the MechTypes field in the initial NegTokenInit
         token.  It allows verifying that the list initially sent by the
         initiator has been received unmodified by the target.



































Zhu, et al.              Expires April 18, 2005                [Page 14]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



5.  Security Considerations


   In order to produce the MIC for the mechanism list, the mechanism
   MUST provide integirty protection.  When one of the mechanisms
   proposed by the initiator does not support integrity protection, then
   the negotiation is exposed to all threats a non secured service is
   exposed.  In particular, an active attacker can force to use a
   security mechanism which is not the common preferred one (when
   multiple security mechanisms are shared between peers) but which is
   acceptable anyway to the target, thus this mechanism does not support
   selecting a mechanism that does not support integrity protection.


   In any case, the communicating peers MAY be exposed to the denial of
   service threat.






































Zhu, et al.              Expires April 18, 2005                [Page 15]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



6.  Acknowledgments


   The authors wish to thank Paul Leach and Todd Stecher for theirs
   comments and suggestions on earlier versions of this document.


   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
   [RFC2478], of which some of the text has been retained in this
   document.


7  References


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
              Negotiation Mechanism", RFC 2478, December 1998.


   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.


   [PRTSTK]   RFC-Editor: To be replaced by RFC number for draft-williams
              -gssapi-stackable-pseudo-mechs.  Work in progress.
              
   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
              (BER), Canonical Encoding Rules (CER) and Distinguished 
              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
              ISO/IEC International Standard 8825-1:1998.


Authors' Addresses


   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US


   EMail: lzhu@microsoft.com



   Karthik Jaganathan
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US


   EMail: karthikj@microsoft.com



   Richard B. Ward
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US


   EMail: richardw@microsoft.com




Zhu, et al.              Expires April 18, 2005                [Page 16]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



Appendix A.  Changes since RFC2478


      The following changes are designed to be compatible with an
      incorrect implementation of RFC 2478 shipped in Windows 2000.  A
      correct implementation of this protocol that negotiates the 2 leg
      Kerberos GSS-API mechanism as the only available security
      mechanism should be ale to interoperate with the implementation of
      Windows 2000 when the mangled OID (1.2.840.48018.1.2.2) can be
      used to identify Kerberos.


      *  The negTokenTarg is changed to negTokenResp and it is now the
         format for all subsequent negotiation messages.
      *  negTokenInit is the message for the initial token and that
         token only.
      *  mechTypes in negTokenInit is no longer optional.
      *  negResult is no longer optional in the negTokenResp token.
      *  The initiator does not send the MIC token.
      *  Add rules when it is safe to omit the MIC token.  Search for
         SOMIC.


      The following changes are to address the problems in RFC 2478.


      *  reqFlags is not protected therefore it should not impact the
         negotiation.
      *  BER encoding is required.
      *  GSS_GetMIC() input is clarified.
      *  Nico's stackable pseudo mechanism draft is used to replace the
         support APIs.
      *  We no longer support negotiating mechanisms that do not provide
         for integrity.  That support does not add security values but
         blows up the interoperability test matrix.





















Zhu, et al.              Expires April 18, 2005                [Page 17]
Internet-Draft       GSS-API Negotiation Mechanism          October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   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
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Zhu, et al.              Expires April 18, 2005                [Page 18]