2.1.11. Channel Bindings

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











 
RFC 1509            GSSAPI - Overview and C bindings      September 1993


                 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




 
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