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

      as the default credentials installed on behalf of a process

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 are exchanged in conjunction with an established context to
   provide protective security services for corresponding data messages.
   The internal contents of both classes of tokens are specific to the
   particular underlying mechanism used to support the GSS-API; Appendix
   B of this document provides a uniform recommendation for designers of
   GSS-API support mechanisms, encapsulating mechanism-specific
   information along with a globally-interpretable mechanism identifier.





 
RFC 1508               Generic Security Interface         September 1993


   Tokens 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 primitives (and are to be transferred to GSS-API peers)
   independent of the status indications which those primitives
   indicate. 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.

   Development of GSS-API support primitives based on a particular
   underlying cryptographic technique and protocol does not necessarily
   imply that GSS-API callers invoking that GSS-API mechanism type will
   be able to interoperate with peers invoking the same technique and
   protocol outside the GSS-API paradigm.  For example, 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 the same as those used by non-GSS-API callers
   of the same underlying technique.

1.1.3.  Security Contexts

   Security contexts are established between peers, using credentials
   established locally in conjunction with each peer or received by
   peers via delegation. Multiple contexts may exist simultaneously
   between a pair of peers, using the same or different sets of
   credentials. Coexistence of multiple contexts using different
   credentials allows graceful rollover when credentials expire.
   Distinction among multiple contexts based on the same credentials
   serves applications by distinguishing different message streams in a
   security sense.

   The GSS-API is independent of underlying protocols and addressing
   structure, and depends on its callers to transport GSS-API-provided
   data elements. As a result of these factors, it is a caller
   responsibility to parse communicated messages, separating GSS-API-
   related data elements from caller-provided data.  The GSS-API is
   independent of connection vs. connectionless orientation of the
   underlying communications service.

   No correlation between security context and communications protocol
   association is dictated. (The optional channel binding facility,
   discussed in Section 1.1.6 of this document, represents an
   intentional exception to this rule, supporting additional protection
   features within GSS-API supporting mechanisms.) This separation
   allows the GSS-API to be used in a wide range of communications




 
RFC 1508               Generic Security Interface         September 1993


   environments, and also simplifies the calling sequences of the
   individual calls. In many cases (depending on underlying security