rfc1509.txt

RFC 的详细文档！

                 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        DARPA Internet address type
          GSS_C_AF_IMPLINK     ARPAnet IMP address type (eg IP)
          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 (eg X.25)
          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         X25
          GSS_C_AF_NULLADDR    No address specified

   Note that these 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 form is
   used.  When not otherwise specified, addresses should be specified in
   network byte-order.

   Conceptually, the GSSAPI concatenates the initiator_addrtype,
   initiator_address, acceptor_addrtype, acceptor_address and
   application_data to form an octet string.  The mechanism signs this
   octet string, and binds the signature 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



Wray                                                           [Page 12]

RFC 1509            GSSAPI - Overview and C bindings      September 1993


   signature is calculated in the same way.  The calculated signature is
   compared with that found in the token, and if the signatures 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
   signature); 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.

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

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

2.1.12.2. Integer types (input)

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

2.1.12.3. Integer types (output)

   Specify NULL as the value for the pointer.

2.1.12.4. Pointer types

   Specify NULL as the value.

2.1.12.5. Object IDs

   Specify GSS_C_NULL_OID as the value.

2.1.12.6. Object ID Sets

   Specify GSS_C_NULL_OID_SET as the value.



Wray                                                           [Page 13]

RFC 1509            GSSAPI - Overview and C bindings      September 1993


2.1.12.7. Credentials

   Specify GSS_C_NO_CREDENTIAL to use the default credential handle.

2.1.12.8. Channel Bindings

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

3. GSSAPI routine descriptions

2.1. gss_acquire_cred

      OM_uint32  gss_acquire_cred (
                     OM_uint32 *     minor_status,
                     gss_name_t      desired_name,
                     OM_uint32       time_req,
                     gss_OID_set     desired_mechs,
                     int             cred_usage,
                     gss_cred_id_t * output_cred_handle,
                     gss_OID_set *   actual_mechs,
                      OM_int32 *      time_rec)
   Purpose:

   Allows an application to acquire a handle for a pre-existing
   credential by name.  GSSAPI implementations must impose a local
   access-control policy on callers of this routine to prevent
   unauthorized callers from acquiring credentials to which they are not
   entitled.  This routine is not intended to provide a "login to the
   network" function, as such a function would result in the creation of
   new credentials rather than merely acquiring a handle to existing
   credentials.  Such functions, if required, should be defined in
   implementation-specific extensions to the API.

   If credential acquisition is time-consuming for a mechanism, the
   mechanism may chooses to delay the actual acquisition until the
   credential is required (e.g., by gss_init_sec_context or
   gss_accept_sec_context).  Such mechanism-specific implementation
   decisions should be invisible to the calling application; thus a call
   of gss_inquire_cred immediately following the call of
   gss_acquire_cred must return valid credential data, and may therefore
   incur the overhead of a deferred credential acquisition.

   Parameters:

      desired_name      gss_name_t, read
                        Name of principal whose credential
                        should be acquired



Wray                                                           [Page 14]

RFC 1509            GSSAPI - Overview and C bindings      September 1993


      time_req          integer, read
                        number of seconds that credentials
                        should remain valid

      desired_mechs     Set of Object IDs, read
                        set of underlying security mechanisms that
                        may be used.  GSS_C_NULL_OID_SET may be used
                        to obtain an implementation-specific default.

      cred_usage        integer, read
                        GSS_C_BOTH - Credentials may be used
                                     either to initiate or accept
                                     security contexts.
                        GSS_C_INITIATE - Credentials will only be
                                         used to initiate security
                                         contexts.
                        GSS_C_ACCEPT - Credentials will only be used to
                                       accept security contexts.

      output_cred_handle   gss_cred_id_t, modify
                           The returned credential handle.

      actual_mechs      Set of Object IDs, modify, optional
                        The set of mechanisms for which the
                        credential is valid.  Specify NULL
                        if not required.

      time_rec          Integer, modify, optional
                        Actual number of seconds for which the
                        returned credentials will remain valid.  If the
                        implementation does not support expiration of
                        credentials, the value GSS_C_INDEFINITE will
                        be returned. Specify NULL if not required

      minor_status      Integer, modify
                        Mechanism specific status code.
   Function value:

      GSS status code:

      GSS_S_COMPLETE    Successful completion

      GSS_S_BAD_MECH    Unavailable mechanism requested

      GSS_S_BAD_NAMETYPE Type contained within desired_name parameter is
                        not supported

      GSS_S_BAD_NAME    Value supplied for desired_name parameter is



Wray                                                           [Page 15]

RFC 1509            GSSAPI - Overview and C bindings      September 1993


                        ill-formed.

      GSS_S_FAILURE     Unspecified failure.  The minor_status parameter
                        contains more detailed information

3.2. gss_release_cred

      OM_uint32  gss_release_cred (
                     OM_uint32 *     minor_status,
                     gss_cred_id_t * cred_handle)

   Purpose:

   Informs GSSAPI that the specified credential handle is no longer
   required by the process.  When all processes have released a
   credential, it will be deleted.

   Parameters:

      cred_handle       gss_cred_id_t, modify, optional
                        buffer containing opaque credential
                        handle.  If  GSS_C_NO_CREDENTIAL  is supplied,
                        the default credential will be released

      minor_status      integer, modify
                        Mechanism specific status code.

   Function value:

      GSS status code:

      GSS_S_COMPLETE    Successful completion

      GSS_S_NO_CRED     Credentials could not be accessed.

















Wray                                                           [Page 16]

RFC 1509            GSSAPI - Overview and C bindings      September 1993


3.3. gss_init_sec_context

      OM_uint32  gss_init_sec_context (
                     OM_uint32 *     minor_status,
                     gss_cred_id_t   claimant_cred_handle,
                     gss_ctx_id_t *  context_handle,
                     gss_name_t      target_name,
                     gss_OID         mech_type,
                     int             req_flags,
                     int             time_req,
                     gss_channel_bindings_t
                                     input_chan_bindings,
                     gss_buffer_t    input_token
                     gss_OID *       actual_mech_type,
                     gss_buffer_t    output_token,
                     int *           ret_flags,
                     OM_uint32 *     time_rec )

   Purpose:

   Initiates the establishment of a security context between the
   application and a remote peer.  Initially, the input_token parameter
   should be specified as GSS_C_NO_BUFFER.  The routine may return a
   output_token which should be transferred to the peer application,
   where the peer application will present it to gss_accept_sec_context.
   If no token need be sent, gss_init_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