rfc2078.txt

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

   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
   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



Linn                        Standards Track                    [Page 20]

RFC 2078                        GSS-API                     January 1997


   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.

1.2.5: Anonymity Support

   In certain situations or environments, an application may wish to
   authenticate a peer and/or protect communications using GSS-API per-
   message services without revealing its own identity.  For example,
   consider an application which provides read access to a research
   database, and which permits queries by arbitrary requestors.  A
   client of such a service might wish to authenticate the service, to
   establish trust in the information received from it, but might not
   wish to disclose its identity to the service for privacy reasons.

   In ordinary GSS-API usage, a context initiator's identity is made
   available to the context acceptor as part of the context
   establishment process.  To provide for anonymity support, a facility
   (input anon_req_flag to GSS_Init_sec_context()) is provided through
   which context initiators may request that their identity not be
   provided to the context acceptor.  Mechanisms are not required to
   honor this request, but a caller will be informed (via returned
   anon_state indicator from GSS_Init_sec_context()) whether or not the
   request is honored. Note that authentication as the anonymous
   principal does not necessarily imply that credentials are not
   required in order to establish a context.

   The following Object Identifier value is provided as a means to
   identify anonymous names, and can be compared against in order to
   determine, in a mechanism-independent fashion, whether a name refers
   to an anonymous principal:

   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
   3(gss-anonymous-name)}

   The recommended symbolic name corresponding to this definition is
   GSS_C_NT_ANONYMOUS.

   Four possible combinations of anon_state and mutual_state are
   possible, with the following results:

      anon_state == FALSE, mutual_state == FALSE: initiator
      authenticated to target.

      anon_state == FALSE, mutual_state == TRUE: initiator authenticated
      to target, target authenticated to initiator.




Linn                        Standards Track                    [Page 21]

RFC 2078                        GSS-API                     January 1997


      anon_state == TRUE, mutual_state == FALSE: initiator authenticated
      as anonymous principal to target.

      anon_state == TRUE, mutual_state == TRUE: initiator authenticated
      as anonymous principal to target, target authenticated to
      initiator.

1.2.6: Initialization

   No initialization calls (i.e., calls which must be invoked prior to
   invocation of other facilities in the interface) are defined in GSS-
   API.  As an implication of this fact, GSS-API implementations must
   themselves be self-initializing.

1.2.7: Per-Message Protection During Context Establishment

   A facility is defined in GSS-V2 to enable protection and buffering of
   data messages for later transfer while a security context's
   establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases
   where the caller side already possesses the necessary session key to
   enable this processing. Specifically, a new state Boolean, called
   prot_ready_state, is added to the set of information returned by
   GSS_Init_sec_context(), GSS_Accept_sec_context(), and
   GSS_Inquire_context().

   For context establishment calls, this state Boolean is valid and
   interpretable when the associated major_status is either
   GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE.  Callers of GSS-API (both
   initiators and acceptors) can assume that per-message protection (via
   GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is
   available and ready for use if either: prot_ready_state == TRUE, or
   major_status == GSS_S_COMPLETE, though mutual authentication (if
   requested) cannot be guaranteed until GSS_S_COMPLETE is returned.

   This achieves full, transparent backward compatibility for GSS-API V1
   callers, who need not even know of the existence of prot_ready_state,
   and who will get the expected behavior from GSS_S_COMPLETE, but who
   will not be able to use per-message protection before GSS_S_COMPLETE
   is returned.

   It is not a requirement that GSS-V2 mechanisms ever return TRUE
   prot_ready_state before completion of context establishment (indeed,
   some mechanisms will not evolve usable message protection keys,
   especially at the context acceptor, before context establishment is
   complete).  It is expected but not required that GSS-V2 mechanisms
   will return TRUE prot_ready_state upon completion of context
   establishment if they support per-message protection at all (however
   GSS-V2 applications should not assume that TRUE prot_ready_state will



Linn                        Standards Track                    [Page 22]

RFC 2078                        GSS-API                     January 1997


   always be returned together with the GSS_S_COMPLETE major_status,
   since GSS-V2 implementations may continue to support GSS-V1 mechanism
   code, which will never return TRUE prot_ready_state).

   When prot_ready_state is returned TRUE, mechanisms shall also set
   those context service indicator flags (deleg_state, mutual_state,
   replay_det_state, sequence_state, anon_state, trans_state,
   conf_avail, integ_avail) which represent facilities confirmed, at
   that time, to be available on the context being established.  In
   situations where prot_ready_state is returned before GSS_S_COMPLETE,
   it is possible that additional facilities may be confirmed and
   subsequently indicated when GSS_S_COMPLETE is returned.

1.2.8: Implementation Robustness

   This section recommends aspects of GSS-API implementation behavior in
   the interests of overall robustness.

   If a token is presented for processing on a GSS-API security context
   and that token is determined to be invalid for that context, the
   context's state should not be disrupted for purposes of processing
   subsequent valid tokens.

   Certain local conditions at a GSS-API implementation (e.g.,
   unavailability of memory) may preclude, temporarily or permanently,
   the successful processing of tokens on a GSS-API security context,
   typically generating GSS_S_FAILURE major_status returns along with
   locally-significant minor_status.  For robust operation under such
   conditions, the following recommendations are made:

      Failing calls should free any memory they allocate, so that
      callers may retry without causing further loss of resources.

      Failure of an individual call on an established context should not
      preclude subsequent calls from succeeding on the same context.

      Whenever possible, it should be possible for
      GSS_Delete_sec_context() calls to be successfully processed even
      if other calls cannot succeed, thereby enabling context-related
      resources to be released.

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



Linn                        Standards Track                    [Page 23]

RFC 2078                        GSS-API                     January 1997


   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.

Table 2:  GSS-API Calls

   CREDENTIAL MANAGEMENT

   GSS_Acquire_cred             acquire credentials for use
   GSS_Release_cred             release credentials after use
   GSS_Inquire_cred             display information about
                                credentials
   GSS_Add_cred                 construct credentials incrementally
   GSS_Inquire_cred_by_mech     display per-mechanism credential
                                information

   CONTEXT-LEVEL CALLS

   GSS_Init_sec_context         initiate outbound security context
   GSS_Accept_sec_context       accept inbound security context
   GSS_Delete_sec_context       flush context when no longer needed
   GSS_Process_context_token    process received control token on
                                context
   GSS_Context_time             indicate validity time remaining on
                                      context
   GSS_Inquire_context          display information about context
   GSS_Wrap_size_limit          determine GSS_Wrap token size limit
   GSS_Export_sec_context       transfer context to other process
   GSS_Import_sec_context       import transferred context

   PER-MESSAGE CALLS

   GSS_GetMIC                   apply integrity check, receive as
                                token separate from message
   GSS_VerifyMIC                validate integrity check token
                                along with message
   GSS_Wrap                     sign, optionally encrypt,
                                encapsulate
   GSS_Unwrap                   decapsulate, decrypt if needed,
                                validate integrity check











Linn                        Standards Track                    [Page 24]

RFC 2078                        GSS-API                     January 1997


   SUPPORT CALLS

   GSS_Display_status           translate status codes to printable
                                form
   GSS_Indicate_mech