rfc2744.txt

RFC 的详细文档！

   gss_accept_sec_context) a credential handle that contains the
   delegated identity, and this credential handle may be used to
   initiate subsequent GSS-API security contexts as an agent or delegate
   of the initiator.  If the original initiator's identity is "A" and
   the delegate's identity is "B", then, depending on the underlying
   mechanism, the identity embodied by the delegated credential may be



Wray                        Standards Track                    [Page 21]

RFC 2744                 GSS-API V2: C-bindings             January 2000


   either "A" or "B acting for A".

   For many mechanisms that support delegation, a simple boolean does
   not provide enough control.  Examples of additional aspects of
   delegation control that a mechanism might provide to an application
   are duration of delegation, network addresses from which delegation
   is valid, and constraints on the tasks that may be performed by a
   delegate.  Such controls are presently outside the scope of the GSS-
   API.  GSS-API implementations supporting mechanisms offering
   additional controls should provide extension routines that allow
   these controls to be exercised (perhaps by modifying the initiator's
   GSS-API credential prior to its use in establishing a context).
   However, the simple delegation control provided by GSS-API should
   always be able to over-ride other mechanism-specific delegation
   controls - If the application instructs gss_init_sec_context() that
   delegation is not desired, then the implementation must not permit
   delegation to occur. This is an exception to the general rule that a
   mechanism may enable services even if they are not requested -
   delegation may only be provided at the explicit request of the
   application.

4.2. Mutual authentication

   Usually, a context acceptor will require that a context initiator
   authenticate itself so that the acceptor may make an access-control
   decision prior to performing a service for the initiator.  In some
   cases, the initiator may also request that the acceptor authenticate
   itself.  GSS-API allows the initiating application to request this
   mutual authentication service by setting a flag when calling
   gss_init_sec_context.

   The initiating application is informed as to whether or not the
   context acceptor has authenticated itself.  Note that some mechanisms
   may not support mutual authentication, and other mechanisms may
   always perform mutual authentication, whether or not the initiating
   application requests it.  In particular, mutual authentication my be
   required by some mechanisms in order to support replay or out-of-
   sequence message detection, and for such mechanisms a request for
   either of these services will automatically enable mutual
   authentication.











Wray                        Standards Track                    [Page 22]

RFC 2744                 GSS-API V2: C-bindings             January 2000


4.3. Replay and out-of-sequence detection

   The GSS-API may provide detection of mis-ordered message once a
   security context has been established.  Protection may be applied to
   messages by either application, by calling either gss_get_mic or
   gss_wrap, and verified by the peer application by calling
   gss_verify_mic or gss_unwrap.

   gss_get_mic calculates a cryptographic MIC over an application
   message, and returns that MIC in a token.  The application should
   pass both the token and the message to the peer application, which
   presents them to gss_verify_mic.

   gss_wrap calculates a cryptographic MIC of an application message,
   and places both the MIC and the message inside a single token.  The
   Application should pass the token to the peer application, which
   presents it to gss_unwrap to extract the message and verify the MIC.

   Either pair of routines may be capable of detecting out-of-sequence
   message delivery, or duplication of messages. Details of such mis-
   ordered messages are indicated through supplementary status bits in
   the major status code returned by gss_verify_mic or gss_unwrap.  The
   relevant supplementary bits are:

   GSS_S_DUPLICATE_TOKEN - The token is a duplicate of one that has
                    already been received and processed.  Only
                    contexts that claim to provide replay detection
                    may set this bit.
   GSS_S_OLD_TOKEN - The token is too old to determine whether or
                    not it is a duplicate.  Contexts supporting
                    out-of-sequence detection but not replay
                    detection should always set this bit if
                    GSS_S_UNSEQ_TOKEN is set; contexts that support
                    replay detection should only set this bit if the
                    token is so old that it cannot be checked for
                    duplication.
   GSS_S_UNSEQ_TOKEN - A later token has already been processed.
   GSS_S_GAP_TOKEN - An earlier token has not yet been received.

   A mechanism need not maintain a list of all tokens that have been
   processed in order to support these status codes.  A typical
   mechanism might retain information about only the most recent "N"
   tokens processed, allowing it to distinguish duplicates and missing
   tokens within the most recent "N" messages; the receipt of a token
   older than the most recent "N" would result in a GSS_S_OLD_TOKEN
   status.





Wray                        Standards Track                    [Page 23]

RFC 2744                 GSS-API V2: C-bindings             January 2000


4.4. Anonymous Authentication

   In certain situations, an application may wish to initiate the
   authentication process to authenticate a peer, without revealing its
   own identity.  As an example, consider an application providing
   access to a database containing medical information, and offering
   unrestricted access to the service.  A client of such a service might
   wish to authenticate the service (in order to establish trust in any
   information retrieved from it), but might not wish the service to be
   able to obtain the client's identity (perhaps due to privacy concerns
   about the specific inquiries, or perhaps simply to avoid being placed
   on mailing-lists).

   In normal use of the GSS-API, the initiator's identity is made
   available to the acceptor as a result of the context establishment
   process.  However, context initiators may request that their identity
   not be revealed to the context acceptor. Many mechanisms do not
   support anonymous authentication, and for such mechanisms the request
   will not be honored.  An authentication token will be still be
   generated, but the application is always informed if a requested
   service is unavailable, and has the option to abort context
   establishment if anonymity is valued above the other security
   services that would require a context to be established.

   In addition to informing the application that a context is
   established anonymously (via the ret_flags outputs from
   gss_init_sec_context and gss_accept_sec_context), the optional
   src_name output from gss_accept_sec_context and gss_inquire_context
   will, for such contexts, return a reserved internal-form name,
   defined by the implementation.

   When presented to gss_display_name, this reserved internal-form name
   will result in a printable name that is syntactically distinguishable
   from any valid principal name supported by the implementation,
   associated with a name-type object identifier with the value
   GSS_C_NT_ANONYMOUS, whose value us given in Appendix A.  The
   printable form of an anonymous name should be chosen such that it
   implies anonymity, since this name may appear in, for example, audit
   logs.  For example, the string "<anonymous>" might be a good choice,
   if no valid printable names supported by the implementation can begin
   with "<" and end with ">".

4.5. Confidentiality

   If a context supports the confidentiality service, gss_wrap may be
   used to encrypt application messages.  Messages are selectively
   encrypted, under the control of the conf_req_flag input parameter to
   gss_wrap.



Wray                        Standards Track                    [Page 24]

RFC 2744                 GSS-API V2: C-bindings             January 2000


4.6. Inter-process context transfer

   GSS-API V2 provides routines (gss_export_sec_context and
   gss_import_sec_context) which allow a security context to be
   transferred between processes on a single machine.  The most common
   use for such a feature is a client-server design where the server is
   implemented as a single process that accepts incoming security
   contexts, which then launches child processes to deal with the data
   on these contexts.  In such a design, the child processes must have
   access to the security context data structure created within the
   parent by its call to gss_accept_sec_context so that they can use
   per-message protection services and delete the security context when
   the communication session ends.

   Since the security context data structure is expected to contain
   sequencing information, it is impractical in general to share a
   context between processes.  Thus GSS-API provides a call
   (gss_export_sec_context) that the process which currently owns the
   context can call to declare that it has no intention to use the
   context subsequently, and to create an inter-process token containing
   information needed by the adopting process to successfully import the
   context.  After successful completion of gss_export_sec_context, the
   original security context is made inaccessible to the calling process
   by GSS-API, and any context handles referring to this context are no
   longer valid.  The originating process transfers the inter-process
   token to the adopting process, which passes it to
   gss_import_sec_context, and a fresh gss_ctx_id_t is created such that
   it is functionally identical to the original context.

   The inter-process token may contain sensitive data from the original
   security context (including cryptographic keys). Applications using
   inter-process tokens to transfer security contexts must take
   appropriate steps to protect these tokens in transit.

   Implementations are not required to support the inter-process
   transfer of security contexts.  The ability to transfer a security
   context is indicated when the context is created, by
   gss_init_sec_context or gss_accept_sec_context setting the
   GSS_C_TRANS_FLAG bit in their ret_flags parameter.

4.7. The use of incomplete contexts

   Some mechanisms may allow the per-message services to be used before
   the context establishment process is complete.  For example, a
   mechanism may include sufficient information in its initial context-
   level token for the context acceptor to immediately decode messages
   protected with gss_wrap or gss_get_mic.  For such a mechanism, the
   initiating application need not wait until subsequent context-level



Wray                        Standards Track                    [Page 25]

RFC 2744                 GSS-API V2: C-bindings             January 2000


   tokens have been sent and received before invoking the per-message
   protection services.

   The ability of a context to provide per-message services in advance
   of complete context establishment is indicated by the setting of the
   GSS_C_PROT_READY_FLAG bit in the ret_flags parameter from
   gss_init_sec_context and gss_accept_sec_context. Applications wishing
   to use per-message protection services on partially-established
   contexts should check this flag before attempting to invoke gss_wrap
   or gss_get_mic.

5. GSS-API Routine Descriptions

   In addition to the explicit major status codes documented here, the
   code GSS_S_FAILURE may be returned by any routine, indicating an
   implementation-specific or mechanism-specific error condition,
   further details of which are reported via the minor_status parameter.

5.1. gss_accept_sec_context

   OM_uint32 gss_accept_sec_context (
     OM_uint32           *minor_status,
     gss_ctx_id_t        *context_handle,
     const gss_cred_id_t acceptor_cred_handle,
     const gss_buffer_t  input_token_buffer,
     const gss_channel_bindings_t  input_chan_bindings,
     const gss_name_t    *src_name,
     gss_OID             *mech_type,
     gss_buffer_t        output_token,
     OM_uint32           *ret_flags,
     OM_uint32           *time_rec,
     gss_cred_id_t       *delegated_cred_handle)

   Purpose:

   Allows a remotely initiated security context between the application
   and a remote peer to be established.  The routine may return a
   output_token which should be transferred to the peer application,
   where the peer application will present it to gss_init_sec_context.
   If no token need be sent, gss_accept_sec_context will indicate this
   by setting the length field of the output_token argument to zero.  To
   complete the context establishment, one or more reply tokens may be
   required from the peer application; if so, gss_accept_sec_context
   will return a status flag of GSS_S_CONTINUE_NEEDED, in which case it
   should be called again when the reply token is received from the peer
   application, passing the token to gss_accept_sec_context via the
   input_token parameters.




Wray                        Standards Track                    [Page 26]

RFC 2744                 GSS-API V2: C-bind