rfc2478.txt

RFC 的详细文档！

Network Working Group                                         E. Baize
Request for Comments: 2478                                   D. Pinkas
Category: Standards Track                                         Bull
                                                         December 1998


         The Simple and Protected GSS-API Negotiation Mechanism

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

1.  ABSTRACT

   This document specifies a Security Negotiation Mechanism for the
   Generic Security Service Application Program Interface (GSS-API)
   which is described in [1].

   The GSS-API 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 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.

   This allows to negotiate different security mechanisms, different
   options within a given security mechanism or different options from
   several security mechanisms.






Baize & Pinkas              Standards Track                     [Page 1]

RFC 2478             GSS-API Negotiation Mechanism         December 1998


   Once the common security mechanism is identified, the security
   mechanism may also negotiate mechanism-specific options during its
   context establishment. This will be inside the mechanism tokens, and
   invisible to the SPNEGO protocol.

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

   In its basic form this protocol requires an extra-round trip. Network
   connection setup is a critical performance characteristic of any
   network infrastructure and extra round trips over WAN links, packet
   radio networks, etc. really make a difference. In order to avoid such
   an extra round trip the initial security token of the preferred
   mechanism for the initiator may be embedded in the initial token. If
   the target preferred mechanism matches the initiator's preferred
   mechanism, no additional round trips are incurred by using the
   negotiation protocol.

   The simple and protected GSS-API mechanism negotiation provides a
   technique to protect the negotiation that must be used when the
   underlying mechanism selected by the target is capable of integrity
   protection.

   When all the mechanisms proposed by the initiator support integrity
   protection or when the selected mechanism supports integrity
   protection, then the negotiation mechanism becomes protected since
   this guarantees that the appropriate mechanism supported by both
   peers has been selected.

   The Simple and Protected GSS-API Negotiation Mechanism uses the
   concepts developed in the GSS-API specification [1]. 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.











Baize & Pinkas              Standards Track                     [Page 2]

RFC 2478             GSS-API Negotiation Mechanism         December 1998


2.  NEGOTIATION MODEL

2.1.  Negotiation description

   The model for security mechanism negotiation reuses a subset of the
   concepts specified in [2].

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

    -  When one security mechanism is proposed by the initiator, it
       represents the only security mechanism supported or selected
       (when the additional APIs defined in the Annex A are used) by the
       initiator.

    -  When several security mechanisms are proposed by the initiator,
       they represent a set of security mechanisms supported or selected
       (when the additional APIs defined in the Annex A are used) by the
       initiator.

   The first negotiation token sent by the initiator contains an ordered
   list of mechanisms, a set of options (e.g. deleg, replay, conf flags)
   that should be supported by the selected mechanism and optionally the
   initial security token for the desired mechanism of the initiator
   (i.e. the first of the list).

   The first negotiation token sent by the target contains the result of
   the negotiation (accept_completed, accept_incomplete or reject) and,
   in case of accept, the agreed security mechanism. It may also include
   the response to the initial security token from the initiator, when
   the first proposed mechanism of the initiator has been selected. When
   the first mechanism is acceptable to the target,it should respond to
   the initial security token for the desired mechanism of the initiator
   when it is present. However, if this is not possible, the target can
   simply ignore it and omit the responseToken from the first reply.

   Implementations that can piggyback the initial token will be rewarded
   by faster connection setup.

   In case of a successful negotiation, the security mechanism
   represents the value suitable for the target, and picked up from the
   list offered by the initiator.  The policy by which the target
   chooses a mechanism is an implementation-specific local matter.  In
   the absence of other policy, the target should chose the first
   mechanism in the list for which valid credentials are available.

   Once a mechanism has been selected, the tokens specific to the
   selected mechanism are carried within the negotiation tokens (in the
   mechToken for the initiator and in the responseToken for the target).



Baize & Pinkas              Standards Track                     [Page 3]

RFC 2478             GSS-API Negotiation Mechanism         December 1998


2.2.  Negotiation procedure

   The negotiation procedure is summarised 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 be 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 sends the token to the target application;

   (d) The GSS-API target deposits the token through invoking
       GSS_Accept_sec_context. The target GSS-API implementation emits a
       negotiation token containing which if any of the proposed
       mechanisms it supports (or has selected).

   If the mechanism selected by the target matches the preferred
   mechanism identified by the initiator and the initiator provides a
   mechToken, the negotiation token response may contain also an initial
   security token from that mechanism.

   If the preferred mechanism is accepted, GSS_Accept_sec_context()
   indicates GSS_S_COMPLETE when unilateral or mutual authentication has
   been performed and involves a single token in either direction.

   If a proposed mechanism is accepted, and it was not the preferred
   mechanism, or if the first negotiation token sent by the initiator
   did not included a mechToken, then the negotiation token response
   sent by the target may contain also a response token from that
   mechanism which transmits mechanism-specific information (e.g. to
   transmit a certificate). The initiator may ignore such an initial
   token if it is not prepared to process it.

   If a proposed mechanism other than the preferred mechanism is
   accepted, or the preferred mechanism is accepted but involves
   multiple exchanges (e.g. challenge-response authentication), then
   GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.






Baize & Pinkas              Standards Track                     [Page 4]

RFC 2478             GSS-API Negotiation Mechanism         December 1998


   If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
   indicates GSS_S_BAD_MECH status. The security context initialisation
   has failed.

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

   (f) The GSS-API initiator deposits the token through invoking
       GSS_Init_sec_context.

   GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED,
   GSS_S_COMPLETE or GSS_S_BAD_MECH status.

      The GSS_S_BAD_MECH status is returned when the negotiation token
      carries a reject result or when the negotiation token carries an
      accept result and the mechanism selected by the target is not
      included in the initial list sent by the initiator.

      The GSS_S_BAD_MIC status is returned when the selected mechanism
      supports a MIC token but the MIC computed over the list of
      mechanisms sent by the initiator is missing or incorrect.

      If the negotiation token carries a reject result, the context
      establishment is impossible. For example, a rejection will occur
      if the target doesn't support the initiator's proposed mechanism
      type(s). Upon failure of the mechanism negotiation procedure, the
      mech_type output parameter value is the negotiation mechanism
      type.

      The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
      token carries an accept result and further tokens must be
      transferred in order to complete context establishment for the
      selected mechanism. In that case GSS_Init_sec_context() returns an
      initial context token as output_token (with the selected
      mechanism's context token encapsulated within that output_token).

      The initiator then sends the output_token to the target. The
      security context initialisation 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 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. When the final negotiation token
      does not contain a MIC, the initiator GSS-API implementation must
      check the returned/selected mechanism is on the originally



Baize & Pinkas              Standards Track                     [Page 5]

RFC 2478             GSS-API Negotiation Mechanism         December 1998


      submitted list of mechanisms and also verify that the selected
      mechanism is not able to support a MIC. When the final negotiation
      token contains a MIC over the initial mechanisms list sent by the
      initiator, the MIC must be verified.

   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.

   The initiator GSS-API calling application may need to know when the
   negotiation exchanges were protected or not. For this, when
   GSS_S_COMPLETE is returned, it can simply test the integ_avail flag.
   When this flag is set it indicates that the negotiation was
   protected.

   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 choice, then an
   additional API has to be used (see Appendix A).

3.  DATA ELEMENTS

3.1.  Mechanism Type

   MechType::= OBJECT IDENTIFIER

   mechType
        Each security mechanism is as defined in [1].

3.2.  Negotiation Tokens

   The syntax of the negotiation tokens follows the InitialContextToken
   syntax defined in [1]. The security mechanism of the initial
   negotiation token is identified by the Object Identifier
   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).








Baize & Pinkas              Standards Track                     [Page 6]