established credentials may exist for the same principal identity
   (for example, as a result of multiple user login sessions) when
   GSS_Acquire_cred() is called; the means used in such cases to select
   a specific credential are local matters.  The input lifetime_req
   argument to GSS_Acquire_cred() may provide useful information for
   local GSS-API implementations to employ in making this disambiguation




 
RFC 1508               Generic Security Interface         September 1993


   in a manner which will best satisfy a caller's intent.

   The lifetime_rec result indicates the length of time for which the
   acquired credentials will be valid, as an offset from the present. A
   mechanism may return a reserved value indicating INDEFINITE if no
   constraints on credential lifetime are imposed.  A caller of
   GSS_Acquire_cred()  can request a length of time for which acquired
   credentials are to be valid (lifetime_req argument), beginning at the
   present, or can request credentials with a default validity interval.
   (Requests for postdated credentials are not supported within the
   GSS-API.) Certain mechanisms and implementations may bind in
   credential validity period specifiers at a point preliminary to
   invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
   user login procedures). As a result, callers requesting non-default
   values for lifetime_req must recognize that such requests cannot
   always be honored and must be prepared to accommodate the use of
   returned credentials with different lifetimes as indicated in
   lifetime_rec.

   The caller of GSS_Acquire_cred() can explicitly specify a set of
   mech_types which are to be accommodated in the returned credentials
   (desired_mechs argument), or can request credentials for a system-
   defined default set of mech_types. Selection of the system-specified
   default set is recommended in the interests of application
   portability. The actual_mechs return value may be interrogated by the
   caller to determine the set of mechanisms with which the returned
   credentials may be used.

2.1.2.  GSS_Release_cred call

   Input:

   o  cred_handle OCTET STRING-NULL specifies default credentials

   Outputs:

   o  major_status INTEGER,

   o  minor_status INTEGER

   Return major_status codes:

   o  GSS_COMPLETE indicates that the credentials referenced by the
      input cred_handle were released for purposes of subsequent access
      by the caller. The effect on other processes which may be
      authorized shared access to such credentials is a local matter.






 
RFC 1508               Generic Security Interface         September 1993


   o  GSS_NO_CRED indicates that no release operation was performed,
      either because the input cred_handle was invalid or because the
      caller lacks authorization to access the referenced credentials.

   o  GSS_FAILURE indicates that the release operation failed for
      reasons unspecified at the GSS-API level.

   Provides a means for a caller to explicitly request that credentials
   be released when their use is no longer required. Note that system-
   specific credential management functions are also likely to exist,
   for example to assure that credentials shared among processes are
   properly deleted when all affected processes terminate, even if no
   explicit release requests are issued by those processes.  Given the
   fact that multiple callers are not precluded from gaining authorized
   access to the same credentials, invocation of GSS_Release_cred()
   cannot be assumed to delete a particular set of credentials on a
   system-wide basis.

2.1.3.  GSS_Inquire_cred call

      Input:

      o  cred_handle OCTET STRING -NULL specifies default credentials

      Outputs:

      o  major_status INTEGER,

      o  minor_status INTEGER,