CVS gss/doc/specification

[gss-commit]

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

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


--- /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-05.txt    
2005/01/24 21:36:27     NONE
+++ /home/cvs/gss/doc/specification/draft-ietf-kitten-2478bis-05.txt    
2005/01/24 21:36:27     1.1


NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                                  P. Leach
Obsoletes: 2478 (if approved)                              K. Jaganathan
Expires: July 27, 2005                             Microsoft Corporation
                                                            W. Ingersoll
                                                        Sun Microsystems
                                                        January 23, 2005


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

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 July 27, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 July 27, 2005                 [Page 1]

Internet-Draft        GSS-API Negotiation Mechanism         January 2005


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

   If per-message integrity services are available on the established
   mechanism context, then the negotiation is protected against an
   attacker forcing the selection of a mechanism not desired by the
   peers.

   This mechanism replaces RFC 2478 in order to fix defects in that
   specification and to describe how to inter-operate with
   implementations of that specification commonly deployed on the
   Internet.

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  . . . . . . . . . . . . . . . . . . . . . . 10
     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . . 10
     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 14
   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 21
     10.2  Informative References . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
   A.  SPNEGO ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 23
   B.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 25
     B.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 25
     B.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 25
   C.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 27
   D.  mechListMIC Computation Example  . . . . . . . . . . . . . . . 29
       Intellectual Property and Copyright Statements . . . . . . . . 30










Zhu, et al.               Expires July 27, 2005                 [Page 2]

Internet-Draft        GSS-API Negotiation Mechanism         January 2005


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, which enables GSS-API
   peers to determine in-band whether their credentials support a common
   set of one or more GSS-API security mechanisms, and if so, to invoke
   the normal security context establishment for a selected common
   security mechanism.  This is most useful for applications which
   depend on GSS-API implementations and share multiple mechanisms
   between the peers.

   The SPNEGO mechanism negotiation is based on the following 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 negotiation is protected to
   ensure that the mechanism list has not been modified.  In cases where
   an attacker could have materially influenced the negotiation, peers
   exchange message integrity code (MIC) tokens to confirm the mechanism
   list has not been modified.  If no action of an attacker could have
   materially modified the outcome of the negotiation, the exchange of
   MIC tokens is optional (see Section 5).  Allowing MIC tokens to be
   optional in this case provides interoperability with existing
   implementations while still protecting the negotiation.  This
   interoperability comes at the cost of increased complexity.

   SPNEGO relies on 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



Zhu, et al.               Expires July 27, 2005                 [Page 3]

Internet-Draft        GSS-API Negotiation Mechanism         January 2005


   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 July 27, 2005                 [Page 4]

Internet-Draft        GSS-API Negotiation Mechanism         January 2005


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 July 27, 2005                 [Page 5]

Internet-Draft        GSS-API Negotiation Mechanism         January 2005


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).  (Note that
   the list MUST NOT contain either this SPNEGO mechanism itself or any
   mechanism for which the client does not have appropriate
   credentials.)

   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)
   being returned in the reply message: 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 security mechanism token embedded in the
   first negotiation message 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, 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.



Zhu, et al.               Expires July 27, 2005                 [Page 6]

Internet-Draft        GSS-API Negotiation Mechanism         January 2005


   In case of an unsuccessful negotiation, the reject state is returned
   and generating a context level negotiation token is OPTIONAL.

   Once a mechanism has been selected, context establishment tokens
   specific to the 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 MUST NOT be used for per-message
   calls.  To guarantee this, the prot_ready_state [RFC2743] MUST be set
   to false on return from GSS_Init_sec_context() and
   GSS_Accept_sec_context() even if the underlying mechanism returned
   true.

   Note that in order to avoid an extra round trip, the first context
   establishment 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.) In addition, using the optimistic
   mechanism token allows the initiator to recover from non-fatal errors
   encountered trying to produce the first mechanism token before a
   mechanism can be selected.  Implementations MAY omit the optimistic
   mechanism token in cases where the likelihood of the initiator's
   preferred mechanism not being selected by the acceptor is significant
   given the cost of generating it.

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 explicitly
      requested or accepted as the default mechanism.

   (b) The initiator GSS-API implementation generates 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.







Zhu, et al.               Expires July 27, 2005                 [Page 7]

Internet-Draft        GSS-API Negotiation Mechanism         January 2005


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



[1280 lines skipped]