CVS gss/doc/specification

[gss-commit]

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

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


--- /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-02.txt    
2004/12/03 18:08:09     NONE
+++ /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-02.txt    
2004/12/03 18:08:09     1.1
NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                                  P. Leach
Obsoletes: 2478 (if approved)                              K. Jaganathan
Expires: June 1, 2005                              Microsoft Corporation
                                                            W. Ingersoll
                                                        Sun Microsystems
                                                        December 1, 2004


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

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 June 1, 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 June 1, 2005                  [Page 1]

Internet-Draft       GSS-API Negotiation Mechanism         December 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 . . . . . . . . 25
























Zhu, et al.               Expires June 1, 2005                  [Page 2]

Internet-Draft       GSS-API Negotiation Mechanism         December 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 does not 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 which are based on GSS-API implementations and share
   multiple mechanisms between the peers.

   The SPNEGO mechanism negotiation is based on the following
   negotiation model: the initiator proposes a list of security
   mechanism(s), in decreasing 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, mechanism-specific
   options MAY be negotiated as part of the selected mechanism's context
   establishment.  These negotiations (if any) are internal to the
   mechanism and opaque to the SPNEGO protocol.  As such they are
   outside the scope of this document.

   If per-message integrity services are available on the established
   mechanism security context, then the peers can exchange MIC tokens to
   ensure that the mechanism list was not tampered with.  This MIC token
   exchange is OPTIONAL if the selected mechanism is the most preferred
   choice of both peers (see Section 5).

   In order to avoid an extra round trip, the first security token of
   the initiator's 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 mechanism token in this
   document.  If the selected mechanism matches the initiator's
   preferred mechanism, no additional round trips need be incurred by
   using this protocol.  In addition, using the optimistic mechanism



Zhu, et al.               Expires June 1, 2005                  [Page 3]

Internet-Draft       GSS-API Negotiation Mechanism         December 2004


   token allows the initiator to recover from non-fatal errors while
   producing the first mechanism token before a mechanism can be
   selected.  Implementations MAY omit the optimistic mechanism token to
   avoid the cost of generating it in cases where the initiator's
   preferred mechanism is not selected by the acceptor.

   SPNEGO relies 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 June 1, 2005                  [Page 4]

Internet-Draft       GSS-API Negotiation Mechanism         December 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 June 1, 2005                  [Page 5]

Internet-Draft       GSS-API Negotiation Mechanism         December 2004


3.  Negotiation Protocol

   When the established mechanism context provides 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 decreasing preference order, favorite
   mechanism first), and optionally the initial mechanism 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 also that the initial 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
   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,
   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 June 1, 2005                  [Page 6]

Internet-Draft       GSS-API Negotiation Mechanism         December 2004


   selected mechanism are carried within the negotiation tokens.

   Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
   mechanism list received 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 that SPNEGO be used.  SPNEGO can either be explicity
      requested or accepted as the default mechanism.

   (b) The initiator GSS-API implementation emits a negotiation token
      containing a list of one or more security mechanisms that are
      available based on the credentials used for this context
      establishment, and optionally the initial mechanism token for the
      first mechanism in the list.

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

      (I) If none of the proposed mechanisms are 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
         acceptor's most preferred mechanism (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
         token containing an accept_complete or accept_incomplete state,



Zhu, et al.               Expires June 1, 2005                  [Page 7]

Internet-Draft       GSS-API Negotiation Mechanism         December 2004


         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 by invoking
      GSS_Accept_sec_context() and if a response mechanism token is
      emitted, it MUST be included in the response negotiation token.

[1003 lines skipped]