protocol, associated mechanism, and availability of cached
   information), the state information required for context setup can be
   sent concurrently with initial signed user data, without interposing
   additional message exchanges.

1.1.4.  Mechanism Types

   In order to successfully establish a security context with a target
   peer, it is necessary to identify an appropriate underlying mechanism
   type (mech_type) which both initiator and target peers support. The
   definition of a mechanism embodies not only the use of a particular
   cryptographic technology (or a hybrid or choice among alternative
   cryptographic technologies), but also definition of the syntax and
   semantics of data element exchanges which that mechanism will employ
   in order to support security services.

   It is recommended that callers initiating contexts specify the
   "default" mech_type value, allowing system-specific functions within
   or invoked by the GSS-API implementation to select the appropriate
   mech_type, but callers may direct that a particular mech_type be
   employed when necessary.

   The means for identifying a shared mech_type to establish a security
   context with a peer will vary in different environments and
   circumstances; examples include (but are not limited to):

      use of a fixed mech_type, defined by configuration, within an
      environment

      syntactic convention on a target-specific basis, through
      examination of a target's name

      lookup of a target's name in a naming service or other database in
      order to identify mech_types supported by that target

      explicit negotiation between GSS-API callers in advance of
      security context setup

   When transferred between GSS-API peers, mech_type specifiers (per
   Appendix B, represented as Object Identifiers (OIDs)) serve to
   qualify the interpretation of associated tokens. (The structure and
   encoding of Object Identifiers is defined in ISO/IEC 8824,
   "Specification of Abstract Syntax Notation One (ASN.1)" and in
   ISO/IEC 8825, "Specification of Basic Encoding Rules for Abstract
   Syntax Notation One (ASN.1)".) Use of hierarchically structured OIDs
   serves to preclude ambiguous interpretation of mech_type specifiers.




 
RFC 1508               Generic Security Interface         September 1993


   The OID representing the DASS MechType, for example, is
   1.3.12.2.1011.7.5.

1.1.5.  Naming

   The GSS-API avoids prescription of naming structures, treating the
   names transferred across the interface in order to initiate and
   accept security contexts as opaque octet string quantities.  This
   approach supports the GSS-API's goal of implementability atop a range
   of underlying security mechanisms, recognizing the fact that
   different mechanisms process and authenticate names which are
   presented in different forms. Generalized services offering
   translation functions among arbitrary sets of naming environments are
   outside the scope of the GSS-API; availability and use of local
   conversion functions to translate among the naming formats supported
   within a given end system is anticipated.

   Two distinct classes of name representations are used in conjunction
   with different GSS-API parameters:

      a printable form (denoted by OCTET STRING), for acceptance from
      and presentation to users; printable name forms are accompanied by
      OID tags identifying the namespace to which they correspond

      an internal form (denoted by INTERNAL NAME), opaque to callers and
      defined by individual GSS-API implementations; GSS-API
      implementations supporting multiple namespace types are
      responsible for maintaining internal tags to disambiguate the
      interpretation of particular names

      Tagging of printable names allows GSS-API callers and underlying
      GSS-API mechanisms to disambiguate name types and to determine
      whether an associated name's type is one which they are capable of
      processing, avoiding aliasing problems which could result from
      misinterpreting a name of one type as a name of another type.

   In addition to providing means for names to be tagged with types,
   this specification defines primitives to support a level of naming
   environment independence for certain calling applications. To provide
   basic services oriented towards the requirements of callers which
   need not themselves interpret the internal syntax and semantics of
   names, GSS-API calls for name comparison (GSS_Compare_name()),
   human-readable display (GSS_Display_name()),  input conversion
   (GSS_Import_name()), and internal name deallocation
   (GSS_Release_name())  functions are defined. (It is anticipated that
   these proposed GSS-API calls will be implemented in many end systems