rfc1508.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,393 行 · 第 1/5 页

Linn                                                           [Page 10]

RFC 1508               Generic Security Interface         September 1993


   with these conventions and those of the networking environment in
   which they operate.

1.2.  GSS-API Features and Issues

   This section describes aspects of GSS-API operations, of the security
   services which the GSS-API provides, and provides commentary on
   design issues.

1.2.1.  Status Reporting

   Each GSS-API call provides two status return values. Major_status
   values provide a mechanism-independent indication of call status
   (e.g., GSS_COMPLETE, GSS_FAILURE, GSS_CONTINUE_NEEDED), sufficient to
   drive normal control flow within the caller in a generic fashion.
   Table 1 summarizes the defined major_status return codes in tabular
   fashion.

   Table 1: GSS-API Major Status Codes

      FATAL ERROR CODES

      GSS_BAD_BINDINGS             channel binding mismatch
      GSS_BAD_MECH                 unsupported mechanism requested
      GSS_BAD_NAME                 invalid name provided
      GSS_BAD_NAMETYPE             name of unsupported type provided
      GSS_BAD_STATUS               invalid input status selector
      GSS_BAD_SIG                  token had invalid signature
      GSS_CONTEXT_EXPIRED          specified security context expired
      GSS_CREDENTIALS_EXPIRED      expired credentials detected
      GSS_DEFECTIVE_CREDENTIAL     defective credential detected
      GSS_DEFECTIVE_TOKEN          defective token detected
      GSS_FAILURE                  failure, unspecified at GSS-API
                                   level
      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



Linn                                                           [Page 11]

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.



Linn                                                           [Page 12]

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
   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.



Linn                                                           [Page 13]

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



Linn                                                           [Page 14]

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,
   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.

2.  Interface Descriptions

   This section describes the GSS-API's service interface, dividing the
   set of calls offered into four groups. Credential management calls
   are related to the acquisition and release of credentials by
   principals. Context-level calls are related to the management of
   security contexts between principals. Per-message calls are related
   to the protection of individual messages on established security
   contexts. Support calls provide ancillary functions useful to GSS-API
   callers. Table 2 groups and summarizes the calls in tabular fashion.