rfc1508.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,393 行 · 第 1/5 页

Linn                                                            [Page 5]

RFC 1508               Generic Security Interface         September 1993


   equipped to handle multiple types to initiate contexts to targets on
   other systems which can accommodate only a subset of the set
   supported at the initiator's system.

   It is the responsibility of underlying system-specific mechanisms and
   OS functions below the GSS-API to ensure that the ability to acquire
   and use credentials associated with a given identity is constrained
   to appropriate processes within a system. This responsibility should
   be taken seriously by implementors, as the ability for an entity to
   utilize a principal's credentials is equivalent to the entity's
   ability to successfully assert that principal's identity.

   Once a set of GSS-API credentials is established, the transferability
   of that credentials set to other processes or analogous constructs
   within a system is a local matter, not defined by the GSS-API. An
   example local policy would be one in which any credentials received
   as a result of login to a given user account, or of delegation of
   rights to that account, are accessible by, or transferable to,
   processes running under that account.

   The credential establishment process (particularly when performed on
   behalf of users rather than server processes) is likely to require
   access to passwords or other quantities which should be protected
   locally and exposed for the shortest time possible. As a result, it
   will often be appropriate for preliminary credential establishment to
   be performed through local means at user login time, with the
   result(s) cached for subsequent reference. These preliminary
   credentials would be set aside (in a system-specific fashion) for
   subsequent use, either:

      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
      call, returning an explicit handle to reference that credential

      as the default credentials installed on behalf of a process

1.1.2. Tokens

   Tokens are data elements transferred between GSS-API callers, and are
   divided into two classes. Context-level tokens are exchanged in order
   to establish and manage a security context between peers. Per-message
   tokens are exchanged in conjunction with an established context to
   provide protective security services for corresponding data messages.
   The internal contents of both classes of tokens are specific to the
   particular underlying mechanism used to support the GSS-API; Appendix
   B of this document provides a uniform recommendation for designers of
   GSS-API support mechanisms, encapsulating mechanism-specific
   information along with a globally-interpretable mechanism identifier.




Linn                                                            [Page 6]

RFC 1508               Generic Security Interface         September 1993


   Tokens are opaque from the viewpoint of GSS-API callers. They are
   generated within the GSS-API implementation at an end system,
   provided to a GSS-API caller to be transferred to the peer GSS-API
   caller at a remote end system, and processed by the GSS-API
   implementation at that remote end system. Tokens may be output by
   GSS-API primitives (and are to be transferred to GSS-API peers)
   independent of the status indications which those primitives
   indicate. Token transfer may take place in an in-band manner,
   integrated into the same protocol stream used by the GSS-API callers
   for other data transfers, or in an out-of-band manner across a
   logically separate channel.

   Development of GSS-API support primitives based on a particular
   underlying cryptographic technique and protocol does not necessarily
   imply that GSS-API callers invoking that GSS-API mechanism type will
   be able to interoperate with peers invoking the same technique and
   protocol outside the GSS-API paradigm.  For example, 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 the same as those 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
   features within GSS-API supporting mechanisms.) This separation
   allows the GSS-API to be used in a wide range of communications



Linn                                                            [Page 7]

RFC 1508               Generic Security Interface         September 1993


   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.

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.



Linn                                                            [Page 8]

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
   based on system-specific name manipulation primitives already extant
   within those end systems; inclusion within the GSS-API is intended to



Linn                                                            [Page 9]

RFC 1508               Generic Security Interface         September 1993


   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.

1.1.6.  Channel Bindings

   The GSS-API accommodates the concept of caller-provided channel
   binding ("chan_binding") information, used by GSS-API callers to bind
   the establishment of a security context to relevant characteristics
   (e.g., addresses, transformed representations of encryption keys) of
   the underlying communications channel and of protection mechanisms
   applied to that communications channel.  Verification by one peer of
   chan_binding information provided by the other peer to a context
   serves to protect against various active attacks. The caller
   initiating a security context must determine the chan_binding values
   before making the GSS_Init_sec_context()  call, and consistent values
   must be provided by both peers to a context. Callers should not
   assume that underlying mechanisms provide confidentiality protection
   for channel binding information.

   Use or non-use of the GSS-API channel binding facility is a caller
   option, and GSS-API supporting mechanisms can support operation in an
   environment where NULL channel bindings are presented. When non-NULL
   channel bindings are used, certain mechanisms will offer enhanced
   security value by interpreting the bindings' content (rather than
   simply representing those bindings, or signatures computed on them,
   within tokens) and will therefore depend on presentation of specific
   data in a defined format. To this end, agreements among mechanism
   implementors are defining conventional interpretations for the
   contents of channel binding arguments, including address specifiers
   (with content dependent on communications protocol environment) for
   context initiators and acceptors. (These conventions are being
   incorporated into related documents.) In order for GSS-API callers to
   be portable across multiple mechanisms and achieve the full security
   functionality available from each mechanism, it is strongly
   recommended that GSS-API callers provide channel bindings consistent