rfc2744.txt

<VC++网络游戏建摸与实现>源代码

   given internal name refer to the same entity, gss_compare_name() can
   return true if the two names have at least one primitive name in
   common.  If the implementation embodies knowledge of equivalence
   relationships between names taken from different namespaces, this
   knowledge may also allow successful comparison of internal names
   containing no overlapping primitive elements.

   When used in large access control lists, the overhead of invoking
   gss_import_name() and gss_compare_name() on each name from the ACL
   may be prohibitive.  As an alternative way of supporting this case,
   GSS-API defines a special form of the contiguous string name which
   may be compared directly (e.g. with memcmp()).  Contiguous names
   suitable for comparison are generated by the gss_export_name()
   routine, which requires an MN as input.  Exported names may be re-
   imported by the gss_import_name() routine, and the resulting internal
   name will also be an MN.  The gss_OID constant GSS_C_NT_EXPORT_NAME
   indentifies the "export name" type, and the value of this constant is
   given in Appendix A.  Structurally, an exported name object consists
   of a header containing an OID identifying the mechanism that
   authenticated the name, and a trailer containing the name itself,
   where the syntax of the trailer is defined by the individual
   mechanism specification.   The precise format of an export name is
   defined in the language-independent GSS-API specification [GSSAPI].

   Note that the results obtained by using gss_compare_name() will in
   general be different from those obtained by invoking
   gss_canonicalize_name() and gss_export_name(), and then comparing the
   exported names.  The first series of operation determines whether two
   (unauthenticated) names identify the same principal; the second
   whether a particular mechanism would authenticate them as the same
   principal.  These two operations will in general give the same
   results only for MNs.

   The gss_name_t datatype should be implemented as a pointer type. To
   allow the compiler to aid the application programmer by performing
   type-checking, the use of (void *) is discouraged.  A pointer to an
   implementation-defined type is the preferred choice.

   Storage is allocated by routines that return gss_name_t values. A
   procedure, gss_release_name, is provided to free storage associated
   with an internal-form name.










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


3.11. Channel Bindings

   GSS-API supports the use of user-specified tags to identify a given
   context to the peer application.  These tags are intended to be used
   to identify the particular communications channel that carries the
   context.  Channel bindings are communicated to the GSS-API using the
   following structure:

   typedef struct gss_channel_bindings_struct {
      OM_uint32       initiator_addrtype;
      gss_buffer_desc initiator_address;
      OM_uint32       acceptor_addrtype;
      gss_buffer_desc acceptor_address;
      gss_buffer_desc application_data;
   } *gss_channel_bindings_t;

   The initiator_addrtype and acceptor_addrtype fields denote the type
   of addresses contained in the initiator_address and acceptor_address
   buffers.  The address type should be one of the following:

   GSS_C_AF_UNSPEC     Unspecified address type
   GSS_C_AF_LOCAL      Host-local address type
   GSS_C_AF_INET       Internet address type (e.g. IP)
   GSS_C_AF_IMPLINK    ARPAnet IMP address type
   GSS_C_AF_PUP        pup protocols (eg BSP) address type
   GSS_C_AF_CHAOS      MIT CHAOS protocol address type
   GSS_C_AF_NS         XEROX NS address type
   GSS_C_AF_NBS        nbs address type
   GSS_C_AF_ECMA       ECMA address type
   GSS_C_AF_DATAKIT    datakit protocols address type
   GSS_C_AF_CCITT      CCITT protocols
   GSS_C_AF_SNA        IBM SNA address type
   GSS_C_AF_DECnet     DECnet address type
   GSS_C_AF_DLI        Direct data link interface address type
   GSS_C_AF_LAT        LAT address type
   GSS_C_AF_HYLINK     NSC Hyperchannel address type
   GSS_C_AF_APPLETALK  AppleTalk address type
   GSS_C_AF_BSC        BISYNC 2780/3780 address type
   GSS_C_AF_DSS        Distributed system services address type
   GSS_C_AF_OSI        OSI TP4 address type
   GSS_C_AF_X25        X.25
   GSS_C_AF_NULLADDR   No address specified

   Note that these symbols name address families rather than specific
   addressing formats.  For address families that contain several
   alternative address forms, the initiator_address and acceptor_address
   fields must contain sufficient information to determine which address




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


   form is used.  When not otherwise specified, addresses should be
   specified in network byte-order (that is, native byte-ordering for
   the address family).

   Conceptually, the GSS-API concatenates the initiator_addrtype,
   initiator_address, acceptor_addrtype, acceptor_address and
   application_data to form an octet string.  The mechanism calculates a
   MIC over this octet string, and binds the MIC to the context
   establishment token emitted by gss_init_sec_context. The same
   bindings are presented by the context acceptor to
   gss_accept_sec_context, and a MIC is calculated in the same way. The
   calculated MIC is compared with that found in the token, and if the
   MICs differ, gss_accept_sec_context will return a GSS_S_BAD_BINDINGS
   error, and the context will not be established.  Some mechanisms may
   include the actual channel binding data in the token (rather than
   just a MIC); applications should therefore not use confidential data
   as channel-binding components.

   Individual mechanisms may impose additional constraints on addresses
   and address types that may appear in channel bindings.  For example,
   a mechanism may verify that the initiator_address field of the
   channel bindings presented to gss_init_sec_context contains the
   correct network address of the host system.  Portable applications
   should therefore ensure that they either provide correct information
   for the address fields, or omit addressing information, specifying
   GSS_C_AF_NULLADDR as the address-types.

3.12. Optional parameters

   Various parameters are described as optional.  This means that they
   follow a convention whereby a default value may be requested.  The
   following conventions are used for omitted parameters.  These
   conventions apply only to those parameters that are explicitly
   documented as optional.

3.12.1. gss_buffer_t types

   Specify GSS_C_NO_BUFFER as a value.  For an input parameter this
   signifies that default behavior is requested, while for an output
   parameter it indicates that the information that would be returned
   via the parameter is not required by the application.

3.12.2. Integer types (input)

   Individual parameter documentation lists values to be used to
   indicate default actions.





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


3.12.3. Integer types (output)

   Specify NULL as the value for the pointer.

3.12.4. Pointer types

   Specify NULL as the value.

3.12.5. Object IDs

   Specify GSS_C_NO_OID as the value.

3.12.6. Object ID Sets

   Specify GSS_C_NO_OID_SET as the value.

3.12.7. Channel Bindings

   Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel bindings
   are not to be used.

4.   Additional Controls

   This section discusses the optional services that a context initiator
   may request of the GSS-API at context establishment. Each of these
   services is requested by setting a flag in the req_flags input
   parameter to gss_init_sec_context.

   The optional services currently defined are:

   Delegation - The (usually temporary) transfer of rights from
       initiator to acceptor, enabling the acceptor to authenticate
       itself as an agent of the initiator.

   Mutual Authentication - In addition to the initiator authenticating
       its identity to the context acceptor, the context acceptor should
       also authenticate itself to the initiator.

   Replay detection - In addition to providing message integrity
       services, gss_get_mic and gss_wrap should include message
       numbering information to enable gss_verify_mic and gss_unwrap to
       detect if a message has been duplicated.

   Out-of-sequence detection - In addition to providing message
       integrity services, gss_get_mic and gss_wrap should include
       message sequencing information to enable gss_verify_mic and
       gss_unwrap to detect if a message has been received out of
       sequence.



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


   Anonymous authentication - The establishment of the security context
       should not reveal the initiator's identity to the context
       acceptor.

   Any currently undefined bits within such flag arguments should be
   ignored by GSS-API implementations when presented by an application,
   and should be set to zero when returned to the application by the
   GSS-API implementation.

   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.

4.1. Delegation

   The GSS-API allows delegation to be controlled by the initiating
   application via a boolean parameter to gss_init_sec_context(), the
   routine that establishes a security context.  Some mechanisms do not
   support delegation, and for such mechanisms attempts by an
   application to enable delegation are ignored.

   The acceptor of a security context for which the initiator enabled
   delegation will receive (via the delegated_cred_handle parameter of
   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 -