The client passes the returned context_token to
   GSS_Process_context_token(),  which returns GSS_COMPLETE status after
   deleting context-level information at the client system.

   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 can be implemented by secret-key technologies (e.g.,
      Kerberos) or public-key approaches (e.g., X.509).

      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 (e.g.,
      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




 
RFC 1508               Generic Security Interface         September 1993


      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

   Credentials structures provide the prerequisites enabling peers to
   establish security contexts with each other. A caller may designate
   that its default credential be used for context establishment calls
   without presenting an explicit handle to that credential.
   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").

   A single credential structure may be used for initiation of outbound
   contexts and acceptance of 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 single credential structure may accommodate credential information
   associated with multiple underlying mechanisms (mech_types); a
   credential structure's contents will vary depending on the set of
   mech_types supported by a particular GSS-API implementation.
   Commonly, a single mech_type will be used for all security contexts
   established by a particular initiator to a particular target; the
   primary motivation for supporting credential sets representing
   multiple mech_types is to allow initiators on systems which are




 
RFC 1508               Generic Security Interface         September 1993


   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.

   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