rfc2853.txt

RFC 的详细文档！

   to explain generic concepts and provide direction to the
   implementors.

   The design goals of this API have been to satisfy all the
   functionality defined in RFC 2743 and to provide these services in an
   object oriented method.  The specification also aims to satisfy the
   needs of both types of Java application developers, those who would
   like access to a "system-wide" GSS-API implementation, as well as
   those who would want to provide their own "custom" implementation.







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


   A "system-wide" implementation is one that is available to all
   applications in the form of a library package.  It may be a standard
   package in the Java runtime environment (JRE) being used or it may be
   additionally installed and accessible to any application via the
   CLASSPATH.

   A "custom" implementation of the GSS-API, on the other hand, is one
   that would, in most cases, be bundled with the application during
   distribution.  It is expected that such an implementation would be
   meant to provide for some particular need of the application, such as
   support for some specific mechanism.

   The design of this API also aims to provide a flexible framework to
   add and manage GSS-API mechanisms. GSS-API leverages the Java
   Cryptography Architecture (JCA) provider model to support the
   plugability of mechanisms.  Mechanisms can be added on a "system-
   wide" basis, where all users of the framework will have them
   available. The specification also allows for the addition of
   mechanisms per-instance of the GSS-API.

   Lastly, this specification presents an API that will naturally fit
   within the operation environment of the Java platform.  Readers are
   assumed to be familiar with both the GSS-API and the Java platform.

2.  GSS-API Operational Paradigm

   The Generic Security Service Application Programming Interface
   Version 2 [GSSAPIv2-UPDATE] defines a generic security API to calling
   applications.  It allows a communicating application to authenticate
   the user associated with another application, to delegate rights to
   another application, and to apply security services such as
   confidentiality and integrity on a per-message basis.

      There are four stages to using GSS-API:

      1) The application acquires a set of credentials with which it may
         prove its identity to other processes.  The application's
         credentials vouch for its global identity, which may or may not
         be related to any local username under which it may be running.

      2) A pair of communicating applications establish a joint security
         context using their credentials.  The security context
         encapsulates shared state information, which is required in
         order that per-message security services may be provided.
         Examples of state information that might be shared between
         applications as part of a security context are cryptographic
         keys, and message sequence numbers.  As part of the
         establishment of  a security context, the context initiator is



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


         authenticated to the responder, and may require that the
         responder is authenticated back to the initiator.  The
         initiator may optionally give the responder the right to
         initiate further security contexts, acting as an agent or
         delegate of the initiator.  This transfer of rights is termed
         "delegation", and is achieved by creating a set of credentials,
         similar to those used by the initiating application, but which
         may be used by the responder.

         A GSSContext object is used to establish and maintain the
         shared information that makes up the security context.  Certain
         GSSContext methods will generate a token, which applications
         treat as cryptographically protected, opaque data.  The caller
         of such GSSContext method is responsible for transferring the
         token to the peer application, encapsulated if necessary in an
         application-to-application protocol.  On receipt of such a
         token, the peer application should pass it to a corresponding
         GSSContext method which will decode the token and extract the
         information, updating the security context state information
         accordingly.

      3) Per-message services are invoked on a GSSContext object to
         apply either:

         integrity and data origin authentication, or

         confidentiality, integrity and data origin authentication

         to application data, which are treated by GSS-API as arbitrary
         octet-strings.  An application transmitting a message that it
         wishes to protect will call the appropriate GSSContext method
         (getMIC or wrap) to apply protection, and send the resulting
         token to the receiving application.  The receiver will pass the
         received token (and, in the case of data protected by getMIC,
         the accompanying message-data) to the corresponding decoding
         method of the GSSContext interface (verifyMIC or unwrap) to
         remove the protection and validate the data.

      4) At the completion of a communications session (which may extend
         across several transport connections), each application uses a
         GSSContext method to invalidate the security context and
         release any system or cryptographic resources held.  Multiple
         contexts may also be used (either successively or
         simultaneously) within a single communications association, at
         the discretion of the applications.






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


3.  Additional Controls

   This section discusses the optional services that a context initiator
   may request of the GSS-API before the context establishment.  Each of
   these services is requested by calling the appropriate mutator method
   in the GSSContext object before the first call to init is performed.
   Only the context initiator can request context flags.

   The optional services defined are:

   Delegation
         The (usually temporary) transfer of rights from initiator to
         acceptor, enabling the acceptor to authenticate itself as an
         agent of the initiator.

   Mutual Authentication
         In addition to the initiator authenticating its identity to the
         context acceptor, the context acceptor should also authenticate
         itself to the initiator.

   Replay Detection
         In addition to providing message integrity services, GSSContext
         per-message operations of getMIC and wrap should include
         message numbering information  to enable verifyMIC and unwrap
         to detect if a message has been duplicated.

   Out-of-Sequence Detection
         In addition to providing message integrity services, GSSContext
         per-message operations  (getMIC and wrap) should include
         message sequencing information to enable verifyMIC and unwrap
         to detect if a message has been received out of sequence.

   Anonymous Authentication
         The establishment of the security context should not reveal the
         initiator's identity to the context acceptor.

   Some mechanisms may not support all optional services, and some
   mechanisms may only support some services in conjunction with others.
   The GSSContext interface offers query methods to allow the
   verification by the calling application of which services will be
   available from the context when the establishment phase is complete.
   In general, if the security mechanism is capable of providing a
   requested service, it should do so even if additional services must
   be enabled in order to provide the requested service.  If the
   mechanism is incapable of providing a requested service, it should
   proceed without the service leaving the application to abort the
   context establishment process if it considers the requested service
   to be mandatory.



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


   Some mechanisms may specify that support for some services is
   optional, and that implementors of the mechanism need not provide it.
   This is most commonly true of the confidentiality service, often
   because of legal restrictions on the use of data-encryption, but may
   apply to any of the services.  Such mechanisms are required to send
   at least one token from acceptor to initiator during context
   establishment when the initiator indicates a desire to use such a
   service, so that the initiating GSS-API can correctly indicate
   whether the service is supported by the acceptor's GSS-API.

3.1.  Delegation

   The GSS-API allows delegation to be controlled by the initiating
   application via the requestCredDeleg method before the first call to
   init has been issued.  Some mechanisms do not support delegation, and
   for such mechanisms attempts by an application to enable delegation
   are ignored.

   The acceptor of a security context, for which the initiator enabled
   delegation, can check if delegation was enabled by using the
   getCredDelegState method of the GSSContext interface.  In cases when
   it is, the delegated credential object can be obtained by calling the
   getDelegCred method.  The obtained GSSCredential object may then be
   used to initiate subsequent GSS-API security contexts as an agent or
   delegate of the initiator.  If the original initiator's identity is
   "A" and the delegate's identity is "B", then, depending on the
   underlying mechanism, the identity embodied by the delegated
   credential may be either "A" or "B acting for A".

   For many mechanisms that support delegation, a simple boolean does
   not provide enough control.  Examples of additional aspects of
   delegation control that a mechanism might provide to an application
   are duration of delegation, network addresses from which delegation
   is valid, and constraints on the tasks that may be performed by a
   delegate.  Such controls are presently outside the scope of the GSS-
   API.  GSS-API implementations supporting mechanisms offering
   additional controls should provide extension routines that allow
   these controls to be exercised (perhaps by modifying the initiator's
   GSS-API credential object prior to its use in establishing a
   context).  However, the simple delegation control provided by GSS-API
   should always be able to over-ride other mechanism-specific
   delegation controls.  If the application instructs the GSSContext
   object that delegation is not desired, then the implementation must
   not permit delegation to occur.  This is an exception to the general
   rule that a mechanism may enable services even if they are not
   requested - delegation may only be provided at the explicit request
   of the application.




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


3.2.  Mutual Authentication

   Usually, a context acceptor will require that a context initiator
   authenticate itself so that the acceptor may make an access-control
   decision prior to performing a service for the initiator.  In some
   cases, the initiator may also request that the acceptor authenticate
   itself.  GSS-API allows the initiating application to request this
   mutual authentication service by calling the requestMutualAuth method
   of the GSSContext interface with a "true" parameter before making the
   first call to init.  The initiating application is informed as to
   whether or not the context acceptor has authenticated itself.  Note
   that some mechanisms may not support mutual authentication, and other
   mechanisms may always perform mutual authentication, whether or not
   the initiating application requests it.  In particular, mutual
   authentication may be required by some mechanisms in order to support
   replay or out-of-sequence message detection, and for such mechanisms
   a request for either of these services will automatically enable
   mutual authentication.

3.3.  Replay and Out-of-Sequence Detection