rfc2743.txt

RFC 的详细文档！

   established context), and it is the responsibility of a GSS-API
   caller receiving tokens to distinguish their types, associate them
   with corresponding security contexts, and pass them to appropriate
   GSS-API processing routines.  Depending on the caller protocol
   environment, this distinction may be accomplished in several ways.

   The following examples illustrate means through which tokens' types
   may be distinguished:

      - implicit tagging based on state information (e.g., all tokens on
      a new association are considered to be context establishment
      tokens until context establishment is completed, at which point
      all tokens are considered to be wrapped data objects for that
      context),





Linn                        Standards Track                    [Page 10]

RFC 2743                        GSS-API                     January 2000


      - explicit tagging at the caller protocol level,

      - a hybrid of these approaches.

   Commonly, the encapsulated data within a token includes internal
   mechanism-specific tagging information, enabling mechanism-level
   processing modules to distinguish tokens used within the mechanism
   for different purposes.  Such internal mechanism-level tagging is
   recommended to mechanism designers, and enables mechanisms to
   determine whether a caller has passed a particular token for
   processing by an inappropriate GSS-API routine.

   Development of GSS-API mechanisms based on a particular underlying
   cryptographic technique and protocol (i.e., conformant to a specific
   GSS-API mechanism definition) does not necessarily imply that GSS-API
   callers using that GSS-API mechanism will be able to interoperate
   with peers invoking the same technique and protocol outside the GSS-
   API paradigm, or with peers implementing a different GSS-API
   mechanism based on the same underlying technology.  The format of
   GSS-API tokens defined in conjunction with a particular mechanism,
   and the techniques used to integrate those tokens into callers'
   protocols, may not be interoperable with the tokens used by non-GSS-
   API callers of the same underlying technique.

1.1.3:  Security Contexts

   Security contexts are established between peers, using credentials
   established locally in conjunction with each peer or received by
   peers via delegation. Multiple contexts may exist simultaneously
   between a pair of peers, using the same or different sets of
   credentials. Coexistence of multiple contexts using different
   credentials allows graceful rollover when credentials expire.
   Distinction among multiple contexts based on the same credentials
   serves applications by distinguishing different message streams in a
   security sense.

   The GSS-API is independent of underlying protocols and addressing
   structure, and depends on its callers to transport GSS-API-provided
   data elements. As a result of these factors, it is a caller
   responsibility to parse communicated messages, separating GSS-API-
   related data elements from caller-provided data.  The GSS-API is
   independent of connection vs. connectionless orientation of the
   underlying communications service.

   No correlation between security context and communications protocol
   association is dictated. (The optional channel binding facility,
   discussed in Section 1.1.6 of this document, represents an
   intentional exception to this rule, supporting additional protection



Linn                        Standards Track                    [Page 11]

RFC 2743                        GSS-API                     January 2000


   features within GSS-API supporting mechanisms.) This separation
   allows the GSS-API to be used in a wide range of communications
   environments, and also simplifies the calling sequences of the
   individual calls. In many cases (depending on underlying security
   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.  Messages may be protected and
   transferred in both directions on an established GSS-API security
   context concurrently; protection of messages in one direction does
   not interfere with protection of messages in the reverse direction.

   GSS-API implementations are expected to retain inquirable context
   data on a context until the context is released by a caller, even
   after the context has expired, although underlying cryptographic data
   elements may be deleted after expiration in order to limit their
   exposure.

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.

   For GSS-API purposes, the phrase "negotiating mechanism" refers to a
   mechanism which itself performs negotiation in order to select a
   concrete mechanism which is shared between peers and is then used for
   context establishment.  Only those mechanisms which are defined in
   their specifications as negotiating mechanisms are to yield selected
   mechanisms with different identifier values than the value which is
   input by a GSS-API caller, except for the case of a caller requesting
   the "default" mech_type.

   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):




Linn                        Standards Track                    [Page 12]

RFC 2743                        GSS-API                     January 2000


      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

      use of a negotiating mechanism

   When transferred between GSS-API peers, mech_type specifiers (per
   Section 3 of this document, represented as Object Identifiers (OIDs))
   serve to qualify the interpretation of associated tokens. (The
   structure and encoding of Object Identifiers is defined in [ISOIEC-
   8824] and [ISOIEC-8825].) Use of hierarchically structured OIDs
   serves to preclude ambiguous interpretation of mech_type specifiers.
   The OID representing the DASS ([RFC-1507]) MechType, for example, is
   1.3.12.2.1011.7.5, and that of the Kerberos V5 mechanism ([RFC-
   1964]), having been advanced to the level of Proposed Standard, is
   1.2.840.113554.1.2.2.

1.1.5:  Naming

   The GSS-API avoids prescribing naming structures, treating the names
   which are transferred across the interface in order to initiate and
   accept security contexts as opaque objects.  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.

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

      - Internal form (denoted in this document by INTERNAL NAME),
      opaque to callers and defined by individual GSS-API
      implementations.  GSS-API implementations supporting multiple
      namespace types must maintain internal tags to disambiguate the
      interpretation of particular names.  A Mechanism Name (MN) is a
      special case of INTERNAL NAME, guaranteed to contain elements




Linn                        Standards Track                    [Page 13]

RFC 2743                        GSS-API                     January 2000


      corresponding to one and only one mechanism; calls which are
      guaranteed to emit MNs or which require MNs as input are so
      identified within this specification.

      - Contiguous string ("flat") form (denoted in this document by
      OCTET STRING); accompanied by OID tags identifying the namespace
      to which they correspond.  Depending on tag value, flat names may
      or may not be printable strings for direct acceptance from and
      presentation to users. Tagging of flat 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.

      - The GSS-API Exported Name Object, a special case of flat name
      designated by a reserved OID value, carries a canonicalized form
      of a name suitable for binary comparisons.

   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()), internal name deallocation (GSS_Release_name()),
   and internal name duplication (GSS_Duplicate_name()) functions are
   defined. (It is anticipated that these proposed GSS-API calls will be
   implemented in many end systems based on system-specific name
   manipulation primitives already extant within those end systems;
   inclusion within the GSS-API is intended to offer GSS-API callers a
   portable means to perform specific operations, supportive of
   authorization and audit requirements, on authenticated names.)

   GSS_Import_name() implementations can, where appropriate, support
   more than one printable syntax corresponding to a given namespace
   (e.g., alternative printable representations for X.500 Distinguished
   Names), allowing flexibility for their callers to select among
   alternative representations. GSS_Display_name() implementations
   output a printable syntax selected as appropriate to their
   operational environments; this selection is a local matter. Callers
   desiring portability across alternative printable syntaxes should
   refrain from implementing comparisons based on printable name forms
   and should instead use the GSS_Compare_name()  call to determine
   whether or not one internal-format name matches another.





Linn                        Standards Track                    [Page 14]

RFC 2743                        GSS-API                     January 2000


   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 symbolic constant GSS_C_NT_EXPORT_NAME
   identifies the "export name" type. 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
   exported name is defined in Section 3.2 of this specification.

   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 operations 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