CVS gss/doc/specification

[gss-commit]

Update of /home/cvs/gss/doc/specification
In directory dopio:/tmp/cvs-serv7692

Added Files:
        draft-ietf-kitten-2478bis-01.txt 
Log Message:
Add.


--- /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-01.txt    
2004/11/30 22:07:55     NONE
+++ /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-01.txt    
2004/11/30 22:07:55     1.1
NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                                  P. Leach
Obsoletes: 2478 (if approved)                              K. Jaganathan
Expires: May 26, 2005                              Microsoft Corporation
                                                            W. Ingersoll
                                                        Sun Microsystems
                                                       November 25, 2004


         The Simple and Protected GSS-API Negotiation Mechanism
                       draft-ietf-kitten-2478bis-01

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 May 26, 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.




Zhu, et al.               Expires May 26, 2005                  [Page 1]

Internet-Draft       GSS-API Negotiation Mechanism         November 2004


   GSS-API peers can use this negotiation mechanism to choose from a
   common set of security mechanisms.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . .  9
     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . .  9
     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . .  9
       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 13
   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   10.   Normative References . . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 21
     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21
     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21
   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24
























Zhu, et al.               Expires May 26, 2005                  [Page 2]

Internet-Draft       GSS-API Negotiation Mechanism         November 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 and multiple
   mechanisms are shared between the peers.

   The SPNEGO mechanism negotiation is based on the following
   negotiation model: the initiator proposes a list of security
   mechanism(s), in its preference order (favorite choice first), the
   acceptor (also known as the target) either accepts the initiator's
   preferred security mechanism (the first in the list), or chooses one
   that is available from the offered list, or rejects the proposed
   value(s).  The target then informs the initiator of its choice.

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

   If per-message integrity services are available on the established
   mechanism security context, the peers can then exchange MIC tokens to
   ensure that the mechanism list was not tampered with.  This MIC token
   exchange is OPTIONAL if no interference could have material impact on
   the negotiation, i.e., when the selected mechanism is the first
   choice for both peers.

   In order to avoid an extra round trip, the first security token of
   the preferred mechanism SHOULD be embedded in the initial negotiation
   message (as defined in Section 4.2).  This mechanism token is
   referred to as the optimistic token in this document.  If the
   selected mechanism matches the initiator's preferred mechanism, no
   additional round trips need to be incurred by using this protocol.
   In addition, by using the optimistic token, the initiator can recover
   from a non-fatal error in producing the first token before a
   mechanism can be selected.  Implementations, however, MAY omit the



Zhu, et al.               Expires May 26, 2005                  [Page 3]

Internet-Draft       GSS-API Negotiation Mechanism         November 2004


   optimistic token, to avoid the cost of generating it in cases where
   the initiator's preferred mechanism is not selected by the acceptor.

   SPNEGO 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 May 26, 2005                  [Page 4]

Internet-Draft       GSS-API Negotiation Mechanism         November 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 May 26, 2005                  [Page 5]

Internet-Draft       GSS-API Negotiation Mechanism         November 2004


3.  Negotiation Protocol

   When the established mechanism context provides for integrity
   protection, the mechanism negotiation can be protected.  When
   acquiring negotiated security mechanism tokens, per-message integrity
   services are always requested by the SPNEGO mechanism.

   When the established mechanism context supports per-message integrity
   services, SPNEGO guarantees that the selected mechanism is mutually
   preferred.

   This section describes the negotiation process of this protocol.

3.1  Negotiation Description

   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 in the list).  The list of security
   mechanisms available for negotiation is based on the credentials
   being used.

   The target then processes the token from the initiator.  This will
   result in one of four possible states (as defined in Section 4.2.2):
   accept_completed, accept_incomplete, reject, or request_mic.  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 further message exchange is needed but the MIC token exchange as
   described in Section 5 is OPITONAL;  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
   implementation-specific local matter.  In the absence of 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, and
   picked up from the list offered by the initiator.  A context level
   token for a reject state is OPTIONAL.

   Once a mechanism has been selected, the tokens specific to the



Zhu, et al.               Expires May 26, 2005                  [Page 6]

Internet-Draft       GSS-API Negotiation Mechanism         November 2004


   selected mechanism are carried within the negotiation tokens.

   Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
   mechanism list as seen by the target.

   To avoid conflicts with the use of MIC tokens by SPNEGO,
   partially-established contexts are not used for per-message calls:
   the prot_ready_state [RFC2743] will be false even if the underlying
   mechanism would return true natively.

3.2  Negotiation Procedure

   The basic form of the procedure assumes that per-message integrity
   services are available on the established mechanism context, and it
   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 this
      negotiation mechanism) that SPNEGO is used.

   (b) The initiator GSS-API implementation emits a negotiation token
      containing a list of supported security mechanisms (possible just
      one mechanism) for the credentials used for this context
      establishment, and optionally an initial security token for the
      first mechanism from that list.

   (c) The GSS-API initiator application sends the token to the target
      application.  The GSS-API target application deposits the token
      through invoking GSS_Accept_sec_context().  The acceptor will do
      one of the following:

      (I) No proposed mechanism is acceptable, the negotiation SHALL be
         terminated.  GSS_Accept_sec_context indicates GSS_S_BAD_MECH.
         The acceptor MAY output a negotiation token containing a reject
         state.

      (II) If either the initiator's preferred mechanism is not accepted
         by the target, or this mechanism is accepted but it is not the
         most preferred mechanism available for the acceptor (see
         Section 3.1 and Section 5), GSS_Accept_sec_context() indicates
         GSS_S_CONTINUE_NEEDED.  The acceptor MUST output a negotiation
         token containing a request_mic state.

      (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
         or GSS_S_CONTINUE_NEEDED, depending on if at least one
         additional negotiation token from the initiator is needed to
         establish this context.  The acceptor outputs a negotiation



Zhu, et al.               Expires May 26, 2005                  [Page 7]

Internet-Draft       GSS-API Negotiation Mechanism         November 2004


         token containing an accept_complete or accept_incomplete state,
         respectively.

      If the initiator's preferred mechanism is accepted, and an
      optimistic mechanism token was included, this mechanism token MUST
      be deposited to the selected mechanism through invoking
      GSS_Accept_sec_context() and if a response mechanism token is

[947 lines skipped]