rfc2078.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,355 行 · 第 1/5 页

      Remote Procedure Call (RPC)) may be interposed between
      applications which call that protocol and the GSS-API, 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



Linn                        Standards Track                     [Page 5]

RFC 2078                        GSS-API                     January 1997


      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
   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



Linn                        Standards Track                     [Page 6]

RFC 2078                        GSS-API                     January 1997


   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.

   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




Linn                        Standards Track                     [Page 7]

RFC 2078                        GSS-API                     January 1997


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.  While individual
   GSS-API implementations are free to determine such default behavior
   as appropriate to the mechanism, the following default behavior by
   these routines is recommended for portability:

   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

      (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




Linn                        Standards Track                     [Page 8]

RFC 2078                        GSS-API                     January 1997


      (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 ones
   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
   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 of this
   document provides, for designers of GSS-API support 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. 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.
   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.




Linn                        Standards Track                     [Page 9]

RFC 2078                        GSS-API                     January 1997


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

      - implicit tagging based on state information (e.g., all tokens on
      a new association are considered to be context establishment
      tokens until context establishment is completed, at which point
      all tokens are considered to be wrapped data objects for that
      context),

      - explicit tagging at the caller protocol level,

      - a hybrid of these approaches.

   Commonly, the encapsulated data within a token includes internal
   mechanism-specific tagging information, enabling mechanism-level
   processing modules to distinguish tokens used within the mechanism
   for different purposes.  Such internal mechanism-level tagging is
   recommended to mechanism designers, and enables mechanisms to
   determine whether a caller has passed a particular token for
   processing by an inappropriate GSS-API routine.

   Development of GSS-API support primitives based on a particular
   underlying cryptographic technique and protocol (i.e., conformant to
   a specific GSS-API mechanism definition) does not necessarily imply
   that GSS-API callers using that GSS-API mechanism will be able to
   interoperate with peers invoking the same technique and protocol
   outside the GSS-API paradigm, or with peers implementing a different
   GSS-API mechanism based on the same underlying technology.  The
   format of GSS-API tokens defined in conjunction with a particular
   mechanism, and the techniques used to integrate those tokens into
   callers' protocols, may not be interoperable with the tokens used by
   non-GSS-API callers of the same underlying technique.