rfc2743.txt

RFC 的详细文档！

   Some mechanisms may not support all optional services, and some
   mechanisms may only support some services in conjunction with others.
   Both GSS_Init_sec_context() and GSS_Accept_sec_context() inform the
   applications which services will be available from the context when
   the establishment phase is complete, via the ret_flags output
   parameter.  In general, if the security mechanism is capable of
   providing a requested service, it should do so, even if additional
   services must be enabled in order to provide the requested service.
   If the mechanism is incapable of providing a requested service, it
   should proceed without the service, leaving the application to abort
   the context establishment process if it considers the requested
   service to be mandatory.

   Some mechanisms may specify that support for some services is
   optional, and that implementors of the mechanism need not provide it.
   This is most commonly true of the confidentiality service, often
   because of legal restrictions on the use of data-encryption, but may
   apply to any of the services.  Such mechanisms are required to send
   at least one token from acceptor to initiator during context
   establishment when the initiator indicates a desire to use such a
   service, so that the initiating GSS-API can correctly indicate
   whether the service is supported by the acceptor's 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





Linn                        Standards Track                    [Page 20]

RFC 2743                        GSS-API                     January 2000


      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_GetMIC() or GSS_Wrap() primitives on the associated
   context will apply no cryptographic protection to user data messages.

   The GSS-API per-message integrity and data origin authentication
   services provide assurance to a receiving caller that protection was
   applied to a message by the caller's peer on the security context,
   corresponding to the entity named at context initiation.  The GSS-API
   per-message confidentiality service provides assurance to a sending
   caller that the message's content is protected from access by
   entities other than the context's named peer.

   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_Wrap(), encapsulate the protected data unit.
   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 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 the selected mechanism,
   without need for bilateral negotiation with the target. When enabled,
   these 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



Linn                        Standards Track                    [Page 21]

RFC 2743                        GSS-API                     January 2000


   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_S_COMPLETE, without concurrent indication of
      GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN, 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_S_DUPLICATE_TOKEN indicates that the cryptographic
      checkvalue on the received message was correct, but that the
      message was recognized as a duplicate of a previously-processed
      message.  In addition to identifying duplicated tokens originated
      by a context's peer, this status may also be used to identify
      reflected copies of locally-generated tokens; it is recommended
      that mechanism designers include within their protocols facilities
      to detect and report such tokens.

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

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

      1. GSS_S_COMPLETE, without concurrent indication of
      GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, or
      GSS_S_GAP_TOKEN, indicates that the message was within the window
      (of time or sequence space) allowing replay events to be detected,
      that the message was not a replay of a previously-processed
      message within that window, and that no predecessor sequenced
      messages are missing relative to the last received message (if
      any) processed on the context with a correct cryptographic
      checkvalue.

      2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value
      on the received message was correct, but that the message was
      recognized as a duplicate of a previously-processed message.  In
      addition to identifying duplicated tokens originated by a
      context's peer, this status may also be used to identify reflected



Linn                        Standards Track                    [Page 22]

RFC 2743                        GSS-API                     January 2000


      copies of locally-generated tokens; it is recommended that
      mechanism designers include within their protocols facilities to
      detect and report such tokens.

      3. GSS_S_OLD_TOKEN indicates that the integrity check value on the
      received message was correct, but that the token is too old to be
      checked for duplication.

      4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue
      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.]

      5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on
      the received message was correct, but that one or more predecessor
      sequenced messages have not been successfully processed relative
      to the last received message (if any) processed on the context
      with a correct cryptographic checkvalue.

   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_GetMIC() and GSS_Wrap(), and would maintain (within a time-
   limited window) a cache (qualified by originator-recipient pair)
   identifying received data elements processed by GSS_VerifyMIC() and
   GSS_Unwrap(). When this feature is active, exception status returns
   (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when



Linn                        Standards Track                    [Page 23]

RFC 2743                        GSS-API                     January 2000


   GSS_VerifyMIC() or GSS_Unwrap() 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 provide their users with fine granularity control
   over the means used to provide per-message protection, allowing
   callers to trade off security processing overhead dynamically against
   the protection requirements of particular messages. A per-message
   quality-of-protection parameter (analogous to quality-of-service, or
   QOS) selects among different QOP options supported by that mechanism.
   On context establishment for a multi-QOP mech_type, context-level
   data provides the prerequisite data for a range of protection
   qualities.

   It is expected that the majority of callers will not wish to exert
   explicit mechanism-specific QOP control and will therefore request
   selection of a default QOP. Definitions of, and choices among, non-
   default QOP values are mechanism-specific, and no ordered sequences
   of QOP values can be assumed equivalent across different mechanisms.
   Meaningful use of non-default QOP values demands that callers be
   familiar with the QOP definitions of an underlying mechanism or
   mechanisms, and is therefore a non-portable construct.  The
   GSS_S_BAD_QOP major_status value is defined in order to indicate that
   a provided QOP value is unsupported for a security context, most
   likely because that value is unrecognized by the underlying
   mechanism.

   In the interests of interoperability, mechanisms which allow optional
   support of particular QOP values shall satisfy one of the following
   conditions.  Either:

      (i) All implementations of the mechanism are required to be
      capable of processing messages protected using any QOP value,
      regardless of whether they can apply protection corresponding to
      that QOP, or

      (ii) The set of mutually-supported receiver QOP values must be
      determined during context establishment, and messages may be
      protected by either peer using only QOP values from this
      mutually-supported set.

   NOTE: (i) is just a special-case of (ii), where implementations are
   required to support all QOP values on receipt.






Linn                        Standards Track                    [Page 24]

RFC 2743                        GSS-API                     January 2000


1.2.5: Anonymity Support

   In certain situations or environments, an application may wish to
   authenticate a peer and/or protect