features provide recipients with indicators as a result of GSS-API
   processing of incoming messages, identifying whether those messages
   were detected as duplicates or out-of-sequence. Detection of such
   events does not prevent a suspect message from being provided to a
   recipient; the appropriate course of action on a suspect message is a
   matter of caller policy.

   The semantics of the replay detection and sequencing services applied
   to received messages, as visible across the interface which the GSS-
   API provides to its clients, are as follows:

   When replay_det_state is TRUE, the possible major_status returns for
   well-formed and correctly signed messages are as follows:

      1. GSS_COMPLETE indicates that the message was within the window
      (of time or sequence space) allowing replay events to be detected,
      and that the message was not a replay of a previously-processed
      message within that window.

      2. GSS_DUPLICATE_TOKEN indicates that the signature on the
      received message was correct, but that the message was recognized
      as a duplicate of a previously-processed message.

      3. GSS_OLD_TOKEN indicates that the signature on the received
      message was correct, but that the message is too old to be checked
      for duplication.




 
RFC 1508               Generic Security Interface         September 1993


   When sequence_state is TRUE, the possible major_status returns for
   well-formed and correctly signed messages are as follows:

      1. GSS_COMPLETE indicates that the message was within the window
      (of time or sequence space) allowing replay events to be detected,
      and that the message was not a replay of a previously-processed
      message within that window.

      2. GSS_DUPLICATE_TOKEN indicates that the signature on the
      received message was correct, but that the message was recognized
      as a duplicate of a previously-processed message.

      3. GSS_OLD_TOKEN indicates that the signature on the received
      message was correct, but that the token is too old to be checked
      for duplication.

      4. GSS_UNSEQ_TOKEN indicates that the signature on the received
      message was correct, but that it is earlier in a sequenced stream
      than a message already processed on the context.  [Note:
      Mechanisms can be architected to provide a stricter form of
      sequencing service, delivering particular messages to recipients
      only after all predecessor messages in an ordered stream have been
      delivered.  This type of support is incompatible with the GSS-API
      paradigm in which recipients receive all messages, whether in
      order or not, and provide them (one at a time, without intra-GSS-
      API message buffering) to GSS-API routines for validation.  GSS-
      API facilities provide supportive functions, aiding clients to
      achieve strict message stream integrity in an efficient manner in
      conjunction with sequencing provisions in communications
      protocols, but the GSS-API does not offer this level of message
      stream integrity service by itself.]

   As the message stream integrity features (especially sequencing) may
   interfere with certain applications' intended communications
   paradigms, and since support for such features is likely to be
   resource intensive, it is highly recommended that mech_types
   supporting these features allow them to be activated selectively on
   initiator request when a context is established. A context initiator
   and target are provided with corresponding indicators
   (replay_det_state and sequence_state), signifying whether these
   features are active on a given context.

   An example mech_type supporting per-message replay detection could
   (when replay_det_state is TRUE) implement the feature as follows: The
   underlying mechanism would insert timestamps in data elements output
   by GSS_Sign() and GSS_Seal(), and would maintain (within a time-
   limited window) a cache (qualified by originator-recipient pair)
   identifying received data elements processed by GSS_Verify() and




 
RFC 1508               Generic Security Interface         September 1993


   GSS_Unseal(). When this feature is active, exception status returns
   (GSS_DUPLICATE_TOKEN, GSS_ OLD_TOKEN) will be provided when
   GSS_Verify() or GSS_Unseal() is presented with a message which is
   either a detected duplicate of a prior message or which is too old to
   validate against a cache of recently received messages.

1.2.4.  Quality of Protection

   Some mech_types will provide their users with fine granularity
   control over the means used to provide per-message protection,