GSS_NO_CONTEXT               no valid security context specified
      GSS_NO_CRED                  no valid credentials provided

      INFORMATORY STATUS CODES

      GSS_COMPLETE                 normal completion
      GSS_CONTINUE_NEEDED          continuation call to routine
                                   required
      GSS_DUPLICATE_TOKEN          duplicate per-message token
                                   detected
      GSS_OLD_TOKEN                timed-out per-message token
                                   detected
      GSS_UNSEQ_TOKEN              out-of-order per-message token
                                   detected




 
RFC 1508               Generic Security Interface         September 1993


   Minor_status provides more detailed status information which may
   include status codes specific to the underlying security mechanism.
   Minor_status values are not specified in this document.

   GSS_CONTINUE_NEEDED major_status returns, and optional message
   outputs, are provided in GSS_Init_sec_context()  and
   GSS_Accept_sec_context()  calls so that different mechanisms'
   employment of different numbers of messages within their
   authentication sequences need not be reflected in separate code paths
   within calling applications. Instead, such cases are accomodated with
   sequences of continuation calls to GSS_Init_sec_context()  and
   GSS_Accept_sec_context().  The same mechanism is used to encapsulate
   mutual authentication within the GSS-API's context initiation calls.

   For mech_types which require interactions with third-party servers in
   order to establish a security context, GSS-API context establishment
   calls may block pending completion of such third-party interactions.
   On the other hand, no GSS-API calls pend on serialized interactions
   with GSS-API peer entities.  As a result, local GSS-API status
   returns cannot reflect unpredictable or asynchronous exceptions
   occurring at remote peers, and reflection of such status information
   is a caller responsibility outside the GSS-API.

1.2.2. Per-Message Security Service Availability

   When a context is established, two flags are returned to indicate the
   set of per-message protection security services which will be
   available on the context:

      the integ_avail flag indicates whether per-message integrity and
      data origin authentication services are available

      the conf_avail flag indicates whether per-message confidentiality
      services are available, and will never be returned TRUE unless the
      integ_avail flag is also returned TRUE

      GSS-API callers desiring per-message security services should
      check the values of these flags at context establishment time, and
      must be aware that a returned FALSE value for integ_avail means
      that invocation of GSS_Sign()  or GSS_Seal() primitives on the
      associated context will apply no cryptographic protection to user
      data messages.

   The GSS-API per-message protection service primitives, as the
   category name implies, are oriented to operation at the granularity
   of protocol data units. They perform cryptographic operations on the
   data units, transfer cryptographic control information in tokens,
   and, in the case of GSS_Seal(), encapsulate the protected data unit.




 
RFC 1508               Generic Security Interface         September 1993


   As such, these primitives are not oriented to efficient data
   protection for stream-paradigm protocols (e.g., Telnet) if
   cryptography must be applied on an octet-by-octet basis.

1.2.3. Per-Message Replay Detection and Sequencing

   Certain underlying mech_types are expected to offer support for
   replay detection and/or sequencing of messages transferred on the
   contexts they support. These optionally-selectable protection
   features are distinct from replay detection and sequencing features
   applied to the context establishment operation itself; the presence
   or absence of context-level replay or sequencing features is wholly a
   function of the underlying mech_type's capabilities, and is not
   selected or omitted as a caller option.

   The caller initiating a context provides flags (replay_det_req_flag
   and sequence_req_flag) to specify whether the use of per-message
   replay detection and sequencing features is desired on the context
   being established. The GSS-API implementation at the initiator system
   can determine whether these features are supported (and whether they
   are optionally selectable) as a function of mech_type, without need
   for bilateral negotiation with the target. When enabled, these