rfc2853.txt

RFC 的详细文档！

   routines returning or accepting textual data will use the String
   object.

4.6.  Object Identifiers

   An Oid object will be used to represent Universal Object Identifiers
   (Oids).  Oids are ISO-defined, hierarchically globally-interpretable
   identifiers used within the GSS-API framework to identify security
   mechanisms and name formats.  The Oid object can be created from a
   string representation of its dot notation (e.g. "1.3.6.1.5.6.2") as
   well as from its ASN.1 DER encoding.  Methods are also provided to
   test equality and provide the DER representation for the object.

   An important feature of the Oid class is that its instances are
   immutable - i.e.  there are no methods defined that allow one to
   change the contents of an Oid.  This property allows one to treat
   these objects as "statics" without the need to perform copies.

   Certain routines allow the usage of a default oid.  A "null" value
   can be used in those cases.

4.7.  Object Identifier Sets

   The Java bindings represents object identifiers sets as arrays of Oid
   objects.  All Java arrays contain a length field which allows for
   easy manipulation and reference.

   In order to support the full functionality of RFC 2743, the Oid class
   includes a method which checks for existence of an Oid object within
   a specified array.  This is equivalent in functionality to
   gss_test_oid_set_member.  The use of Java arrays and Java's automatic
   garbage collection has eliminated the need for the following
   routines: gss_create_empty_oid_set, gss_release_oid_set, and
   gss_add_oid_set_member.  Java GSS-API implementations will not
   contain them.  Java's automatic garbage collection and the immutable
   property of the Oid object eliminates the complicated memory
   management issues of the C counterpart.

   When ever a default value for an Object Identifier Set is required, a
   "null" value can be used.  Please consult the detailed method
   description for details.





Kabat & Upadhyay            Standards Track                    [Page 15]

RFC 2853                 GSS-API Java Bindings                 June 2000


4.8.  Credentials

   GSS-API credentials are represented by the GSSCredential interface.
   The interface contains several constructs to allow for the creation
   of most common credential objects for the initiator and the acceptor.
   Comparisons are performed using the interface's "equals" method.  The
   following general description of GSS-API credentials is included from
   the C-bindings specification:

   GSS-API credentials can contain mechanism-specific principal
   authentication data for multiple mechanisms.  A GSS-API credential is
   composed of a set of credential-elements, each of which is applicable
   to a single mechanism.  A credential may contain at most one
   credential-element for each supported mechanism.  A credential-
   element identifies the data needed by a single mechanism to
   authenticate a single principal, and conceptually contains two
   credential-references that describe the actual mechanism-specific
   authentication data, one to be used by GSS-API for initiating
   contexts, and one to be used for accepting contexts.  For mechanisms
   that do not distinguish between acceptor and initiator credentials,
   both references would point to the same underlying mechanism-specific
   authentication data.

   Credentials describe a set of mechanism-specific principals, and give
   their holder the ability to act as any of those principals.  All
   principal identities asserted by a single GSS-API credential should
   belong to the same entity, although enforcement of this property is
   an implementation-specific matter.  A single GSSCredential object
   represents all the credential elements that have been acquired.

   The creation's of an GSSContext object allows the value of "null" to
   be specified as the GSSCredential input parameter.  This will
   indicate a desire by the application to act as a default principal.
   While individual GSS-API implementations are free to determine such
   default behavior as appropriate to the mechanism, the following
   default behavior by these routines is recommended for portability:

      For the initiator side of the context:

      1) If there is only a single principal capable of initiating
         security contexts for the chosen mechanism that the application
         is authorized to act on behalf of, then that principal shall be
         used, otherwise








Kabat & Upadhyay            Standards Track                    [Page 16]

RFC 2853                 GSS-API Java Bindings                 June 2000


      2) If the platform maintains a concept of a default network-
         identity for the chosen mechanism, and if the application is
         authorized to act on behalf of that identity for the purpose of
         initiating security contexts, then the principal corresponding
         to that identity shall be used, otherwise

      3) If the platform maintains a concept of a default local
         identity, and provides a means to map local identities into
         network-identities for the chosen mechanism, and if the
         application is authorized to act on behalf of the network-
         identity image of the default local identity for the purpose of
         initiating security contexts using the chosen mechanism, then
         the principal corresponding to that identity shall be used,
         otherwise

      4) A user-configurable default identity should be used.

      and for the acceptor side of the context

      1) If there is only a single authorized principal identity capable
         of accepting security contexts for the chosen mechanism, then
         that principal shall be used, otherwise

      2) If the mechanism can determine the identity of the target
         principal by examining the context-establishment token
         processed during the accept method, and if the accepting
         application is authorized to act as that principal for the
         purpose of accepting security contexts using the chosen
         mechanism, then that principal identity shall be used,
         otherwise

      3) If the mechanism supports context acceptance by any principal,
         and if mutual authentication was not requested, any principal
         that the application is authorized to accept security contexts
         under using the chosen mechanism may be used, otherwise

      4) A user-configurable default identity shall be used.

   The purpose of the above rules is to allow security contexts to be
   established by both initiator and acceptor using the default behavior
   whenever possible.  Applications requesting default behavior are
   likely to be more portable across mechanisms and implementations than
   ones that instantiate an GSSCredential object representing a specific
   identity.







Kabat & Upadhyay            Standards Track                    [Page 17]

RFC 2853                 GSS-API Java Bindings                 June 2000


4.9.  Contexts

   The GSSContext interface is used to represent one end of a GSS-API
   security context, storing state information appropriate to that end
   of the peer communication, including cryptographic state information.
   The instantiation of the context object is done differently by the
   initiator and the acceptor.  After the context has been instantiated,
   the initiator may choose to set various context options which will
   determine the characteristics of the desired security context.  When
   all the application desired characteristics have been set, the
   initiator will call the initSecContext method which will produce a
   token for consumption by the peer's acceptSecContext method.  It is
   the responsibility of the application to deliver the authentication
   token(s) between the peer applications for processing.  Upon
   completion of the context establishment phase, context attributes can
   be retrieved, by both the initiator and acceptor, using the accessor
   methods.  These will reflect the actual attributes of the established
   context.  At this point the context can be used by the application to
   apply cryptographic services to its data.

4.10.  Authentication tokens

   A token is a caller-opaque type that GSS-API uses to maintain
   synchronization between each end of the GSS-API security context.
   The token is a cryptographically protected octet-string, generated by
   the underlying mechanism at one end of a GSS-API security context for
   use by the peer mechanism at the other end.  Encapsulation (if
   required) within the application protocol and transfer of the token
   are the responsibility of the peer applications.

   Java GSS-API uses byte arrays to represent authentication tokens.
   Overloaded methods exist which allow the caller to supply input and
   output streams which will be used for the reading and writing of the
   token data.

4.11.  Interprocess tokens

   Certain GSS-API routines are intended to transfer data between
   processes in multi-process programs.  These routines use a caller-
   opaque octet-string, generated by the GSS-API in one process for use
   by the GSS-API in another process.  The calling application is
   responsible for transferring such tokens between processes.  Note
   that, while GSS-API implementors are encouraged to avoid placing
   sensitive information within interprocess tokens, or to
   cryptographically protect them, many implementations will be unable
   to avoid placing key material or other sensitive data within them.
   It is the application's responsibility to ensure that interprocess
   tokens are protected in transit, and transferred only to processes



Kabat & Upadhyay            Standards Track                    [Page 18]

RFC 2853                 GSS-API Java Bindings                 June 2000


   that are trustworthy.  An interprocess token is represented using a
   byte array emitted from the export method of the GSSContext
   interface.  The receiver of the interprocess token would initialize
   an GSSContext object with this token to create a new context.  Once a
   context has been exported, the GSSContext object is invalidated and
   is no longer available.

4.12.  Error Reporting

   RFC 2743 defined the usage of major and minor status values for
   signaling of GSS-API errors.  The major code, also called GSS status
   code, is used to signal errors at the GSS-API level independent of
   the underlying mechanism(s).  The minor status value or Mechanism
   status code, is a mechanism defined error value indicating a
   mechanism specific error code.

   Java GSS-API uses exceptions implemented by the GSSException class to
   signal both minor and major error values.  Both mechanism specific
   errors and GSS-API level errors are signaled through instances of
   this class.  The usage of exceptions replaces the need for major and
   minor codes to be used within the API calls.  GSSException class also
   contains methods to obtain textual representations for both the major
   and minor values, which is equivalent to the functionality of
   gss_display_status.

4.12.1.  GSS status codes

   GSS status codes indicate errors that are independent of the
   underlying mechanism(s) used to provide the security service.  The
   errors that can be indicated via a GSS status code are generic API
   routine errors (errors that are defined in the GSS-API
   specification).  These bindings take advantage of the Java exceptions
   mechanism, thus eliminating the need for calling errors.

   A GSS status code indicates a single fatal generic API error from the
   routine that has thrown the GSSException.  Using exceptions announces
   that a fatal error has occurred during the execution of the method.
   The GSS-API operational model also allows for the signaling of
   supplementary status information from the per-message calls.  These
   need to be handled as return values since using exceptions is not
   appropriate for informatory or warning-like information.  The methods
   that are capable of producing supplementary information are the two
   per-message methods GSSContext.verifyMIC() and GSSContext.unwrap().
   These methods fill the supplementary status codes in the MessageProp
   object that was passed in.