rfc2743.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   client system.




Linn                        Standards Track                     [Page 5]

RFC 2743                        GSS-API                     January 2000


   The GSS-API design assumes and addresses several basic goals,
   including:

      Mechanism independence: The GSS-API defines an interface to
      cryptographically implemented strong authentication and other
      security services at a generic level which is independent of
      particular underlying mechanisms. For example, GSS-API-provided
      services have been implemented using secret-key technologies
      (e.g., Kerberos, per [RFC-1964]) and with public-key approaches
      (e.g., SPKM, per [RFC-2025]).

      Protocol environment independence: The GSS-API is independent of
      the communications protocol suites with which it is employed,
      permitting use in a broad range of protocol environments. In
      appropriate environments, an intermediate implementation "veneer"
      which is oriented to a particular communication protocol may be
      interposed between applications which call that protocol and the
      GSS-API (e.g., as defined in [RFC-2203] for Open Network Computing
      Remote Procedure Call (RPC)), thereby invoking GSS-API facilities
      in conjunction with that protocol's communications invocations.

      Protocol association independence: The GSS-API's security context
      construct is independent of communications protocol association
      constructs. This characteristic allows a single GSS-API
      implementation to be utilized by a variety of invoking protocol
      modules on behalf of those modules' calling applications. GSS-API
      services can also be invoked directly by applications, wholly
      independent of protocol associations.

      Suitability to a range of implementation placements: GSS-API
      clients are not constrained to reside within any Trusted Computing
      Base (TCB) perimeter defined on a system where the GSS-API is
      implemented; security services are specified in a manner suitable
      to both intra-TCB and extra-TCB callers.

1.1: GSS-API Constructs

   This section describes the basic elements comprising the GSS-API.

1.1.1:  Credentials

1.1.1.1: Credential Constructs and Concepts

   Credentials provide the prerequisites which permit GSS-API peers to
   establish security contexts with each other. A caller may designate
   that the credential elements which are to be applied for context
   initiation or acceptance be selected by default.  Alternately, those
   GSS-API callers which need to make explicit selection of particular



Linn                        Standards Track                     [Page 6]

RFC 2743                        GSS-API                     January 2000


   credentials structures may make references to those credentials
   through GSS-API-provided credential handles ("cred_handles").  In all
   cases, callers' credential references are indirect, mediated by GSS-
   API implementations and not requiring callers to access the selected
   credential elements.

   A single credential structure may be used to initiate outbound
   contexts and to accept inbound contexts. Callers needing to operate
   in only one of these modes may designate this fact when credentials
   are acquired for use, allowing underlying mechanisms to optimize
   their processing and storage requirements. The credential elements
   defined by a particular mechanism may contain multiple cryptographic
   keys, e.g., to enable authentication and message encryption to be
   performed with different algorithms.

   A GSS-API credential structure may contain multiple credential
   elements, each containing mechanism-specific information for a
   particular underlying mechanism (mech_type), but the set of elements
   within a given credential structure represent a common entity.  A
   credential structure's contents will vary depending on the set of
   mech_types supported by a particular GSS-API implementation. Each
   credential element identifies the data needed by its mechanism in
   order to establish contexts on behalf of a particular principal, and
   may contain separate credential references for use in context
   initiation and context acceptance.  Multiple credential elements
   within a given credential having overlapping combinations of
   mechanism, usage mode, and validity period are not permitted.

   Commonly, a single mech_type will be used for all security contexts
   established by a particular initiator to a particular target. A major
   motivation for supporting credential sets representing multiple
   mech_types is to allow initiators on systems which are equipped to
   handle multiple types to initiate contexts to targets on other
   systems which can accommodate only a subset of the set supported at
   the initiator's system.

1.1.1.2: Credential Management

   It is the responsibility of underlying system-specific mechanisms and
   OS functions below the GSS-API to ensure that the ability to acquire
   and use credentials associated with a given identity is constrained
   to appropriate processes within a system. This responsibility should
   be taken seriously by implementors, as the ability for an entity to
   utilize a principal's credentials is equivalent to the entity's
   ability to successfully assert that principal's identity.






Linn                        Standards Track                     [Page 7]

RFC 2743                        GSS-API                     January 2000


   Once a set of GSS-API credentials is established, the transferability
   of that credentials set to other processes or analogous constructs
   within a system is a local matter, not defined by the GSS-API. An
   example local policy would be one in which any credentials received
   as a result of login to a given user account, or of delegation of
   rights to that account, are accessible by, or transferable to,
   processes running under that account.

   The credential establishment process (particularly when performed on
   behalf of users rather than server processes) is likely to require
   access to passwords or other quantities which should be protected
   locally and exposed for the shortest time possible. As a result, it
   will often be appropriate for preliminary credential establishment to
   be performed through local means at user login time, with the
   result(s) cached for subsequent reference. These preliminary
   credentials would be set aside (in a system-specific fashion) for
   subsequent use, either:

      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
      call, returning an explicit handle to reference that credential

      to comprise default credential elements to be installed, and to be
      used when default credential behavior is requested on behalf of a
      process

1.1.1.3: Default Credential Resolution

   The GSS_Init_sec_context() and GSS_Accept_sec_context() routines
   allow the value GSS_C_NO_CREDENTIAL to be specified as their
   credential handle parameter.  This special credential handle
   indicates a desire by the application to act as a default principal.
   In support of application portability, support for the default
   resolution behavior described below for initiator credentials
   (GSS_Init_sec_context() usage) is mandated; support for the default
   resolution behavior described below for acceptor credentials
   (GSS_Accept_sec_context() usage) is recommended. If default
   credential resolution fails, GSS_S_NO_CRED status is to be returned.

      GSS_Init_sec_context:

         (i) If there is only a single principal capable of initiating
         security contexts that the application is authorized to act on
         behalf of, then that principal shall be used, otherwise








Linn                        Standards Track                     [Page 8]

RFC 2743                        GSS-API                     January 2000


         (ii) If the platform maintains a concept of a default network-
         identity, and if the application is authorized to act on behalf
         of that identity for the purpose of initiating security
         contexts, then the principal corresponding to that identity
         shall be used, otherwise

         (iii) If the platform maintains a concept of a default local
         identity, and provides a means to map local identities into
         network-identities, and if the application is authorized to act
         on behalf of the network-identity image of the default local
         identity for the purpose of initiating security contexts, then
         the principal corresponding to that identity shall be used,
         otherwise

         (iv) A user-configurable default identity should be used.

      GSS_Accept_sec_context:

         (i) If there is only a single authorized principal identity
         capable of accepting security contexts, then that principal
         shall be used, otherwise

         (ii) If the mechanism can determine the identity of the target
         principal by examining the context-establishment token, and if
         the accepting application is authorized to act as that
         principal for the purpose of accepting security contexts, then
         that principal identity shall be used, otherwise

         (iii) If the mechanism supports context acceptance by any
         principal, and mutual authentication was not requested, any
         principal that the application is authorized to accept security
         contexts under may be used, otherwise

         (iv) A user-configurable default identity shall be used.

   The purpose of the above rules is to allow security contexts to be
   established by both initiator and acceptor using the default behavior
   wherever possible.  Applications requesting default behavior are
   likely to be more portable across mechanisms and platforms than those
   that use GSS_Acquire_cred() to request a specific identity.

1.1.2: Tokens

   Tokens are data elements transferred between GSS-API callers, and are
   divided into two classes. Context-level tokens are exchanged in order
   to establish and manage a security context between peers. Per-message
   tokens relate to an established context and are exchanged to provide




Linn                        Standards Track                     [Page 9]

RFC 2743                        GSS-API                     January 2000


   protective security services (i.e., data origin authentication,
   integrity, and optional confidentiality) for corresponding data
   messages.

   The first context-level token obtained from GSS_Init_sec_context() is
   required to indicate at its very beginning a globally-interpretable
   mechanism identifier, i.e., an Object Identifier (OID) of the
   security mechanism. The remaining part of this token as well as the
   whole content of all other tokens are specific to the particular
   underlying mechanism used to support the GSS-API. Section 3.1 of this
   document provides, for designers of GSS-API mechanisms, the
   description of the header of the first context-level token which is
   then followed by mechanism-specific information.

   Tokens' contents are opaque from the viewpoint of GSS-API callers.
   They are generated within the GSS-API implementation at an end
   system, provided to a GSS-API caller to be transferred to the peer
   GSS-API caller at a remote end system, and processed by the GSS-API
   implementation at that remote end system.

   Context-level tokens may be output by GSS-API calls (and should be
   transferred to GSS-API peers) whether or not the calls' status
   indicators indicate successful completion.  Per-message tokens, in
   contrast, are to be returned only upon successful completion of per-
   message calls. Zero-length tokens are never returned by GSS routines
   for transfer to a peer. Token transfer may take place in an in-band
   manner, integrated into the same protocol stream used by the GSS-API
   callers for other data transfers, or in an out-of-band manner across
   a logically separate channel.

   Different GSS-API tokens are used for different purposes (e.g.,
   context initiation, context acceptance, protected message data on an
   established context), and it is the responsibility of a GSS-API
   caller receiving tokens to distinguish their types, associate them
   with corresponding security contexts, and pass them to appropriate
   GSS-API processing routines.  Depending on the caller protocol
   environment, this distinction may be accomplished in several ways.

   The following examples illustrate means through which tokens' types
   may be distinguished:

      - implicit tagging based on state information (e.g., all tokens on