rfc2853.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   peer's GSSContext object.

   The wrap method calculates a cryptographic checksum of an application
   message, and places both the checksum and the message inside a single
   token.  The application should pass the token to the peer
   application, which presents it to the unwrap method of the peer's
   GSSContext object to extract the message and verify the checksum.

   Either pair of routines may be capable of detecting out-of-sequence
   message delivery, or duplication of messages.  Details of such mis-
   ordered messages are indicated through supplementary query methods of
   the MessageProp object that is filled in by each of these routines.

   A mechanism need not maintain a list of all tokens that have been
   processed in order to support these status codes.  A typical
   mechanism might retain information about only the most recent "N"



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


   tokens processed, allowing it to distinguish duplicates and missing
   tokens within the most recent "N" messages; the receipt of a token
   older than the most recent "N" would result in the isOldToken method
   of the instance of MessageProp to return "true".

3.4.  Anonymous Authentication

   In certain situations, an application may wish to initiate the
   authentication process to authenticate a peer, without revealing its
   own identity.  As an example, consider an application providing
   access to a database containing medical information, and offering
   unrestricted access to the service.  A client of such a service might
   wish to authenticate the service (in order to establish trust in any
   information retrieved from it), but might not wish the service to be
   able to obtain the client's identity (perhaps due to privacy concerns
   about the specific inquiries, or perhaps simply to avoid being placed
   on mailing-lists).

   In normal use of the GSS-API, the initiator's identity is made
   available to the acceptor as a result of the context establishment
   process.  However, context initiators may request that their identity
   not be revealed to the context acceptor.  Many mechanisms do not
   support anonymous authentication, and for such mechanisms the request
   will not be honored.  An authentication token will still be
   generated, but the application is always informed if a requested
   service is unavailable, and has the option to abort context
   establishment if anonymity is valued above the other security
   services that would require a context to be established.

   In addition to informing the application that a context is
   established anonymously (via the isAnonymous method of the GSSContext
   class), the getSrcName method of the acceptor's GSSContext object
   will, for such contexts, return a reserved internal-form name,
   defined by the implementation.

   The toString method for a GSSName object representing an anonymous
   entity will return a printable name.  The returned value will be
   syntactically distinguishable from any valid principal name supported
   by the implementation.  The associated name-type object identifier
   will be an oid representing the value of NT_ANONYMOUS.  This name-
   type oid will be defined as a public, static Oid object of the
   GSSName class.  The printable form of an anonymous name should be
   chosen such that it implies anonymity, since this name may appear in,
   for example, audit logs.  For example, the string "<anonymous>" might
   be a good choice, if no valid printable names supported by the
   implementation can begin with "<" and end with ">".





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


   When using the equal method of the GSSName interface, and one of the
   operands is a GSSName instance representing an anonymous entity, the
   method must return "false".

3.5.  Confidentiality

   If a GSSContext supports the confidentiality service, wrap method may
   be used to encrypt application messages.  Messages are selectively
   encrypted, under the control of the setPrivacy method of the
   MessageProp object used in the wrap method.

3.6.  Inter-process Context Transfer

   GSS-API V2 provides functionality which allows a security context to
   be transferred between processes on a single machine.  These are
   implemented using the export method of GSSContext and a byte array
   constructor of the same class.  The most common use for such a
   feature is a client-server design where the server is implemented as
   a single process that accepts incoming security contexts, which then
   launches child processes to deal with the data on these contexts.  In
   such a design, the child processes must have access to the security
   context object created within the parent so that they can use per-
   message protection services and delete the security context when the
   communication session ends.

   Since the security context data structure is expected to contain
   sequencing information, it is impractical in general to share a
   context between processes.  Thus GSSContext interface provides an
   export method that the process, which currently owns the context, can
   call to declare that it has no intention to use the context
   subsequently, and to create an inter-process token containing
   information needed by the adopting process to successfully re-create
   the context.  After successful completion of export, the original
   security context is made inaccessible to the calling process by GSS-
   API and any further usage of this object will result in failures.
   The originating process transfers the inter-process token to the
   adopting process, which creates a new GSSContext object using the
   byte array constructor.  The properties of the context are equivalent
   to that of the original context.

   The inter-process token may contain sensitive data from the original
   security context (including cryptographic keys).  Applications using
   inter-process tokens to transfer security contexts must take
   appropriate steps to protect these tokens in transit.







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


   Implementations are not required to support the inter-process
   transfer of security contexts.  Calling the isTransferable method of
   the GSSContext interface will indicate if the context object is
   transferable.

3.7.  The Use of Incomplete Contexts

   Some mechanisms may allow the per-message services to be used before
   the context establishment process is complete.  For example, a
   mechanism may include sufficient information in its initial context-
   level tokens for the context acceptor to immediately decode messages
   protected with wrap or getMIC.  For such a mechanism, the initiating
   application need not wait until subsequent context-level tokens have
   been sent and received before invoking the per-message protection
   services.

   An application can invoke the isProtReady method of the GSSContext
   class to determine if the per-message services are available in
   advance of complete context establishment.  Applications wishing to
   use per-message protection services on partially-established contexts
   should query this method before attempting to invoke wrap or getMIC.

4.  Calling Conventions

   Java provides the implementors with not just a syntax for the
   language, but also an operational environment.  For example, memory
   is automatically managed and does not require application
   intervention.  These language features have allowed for a simpler API
   and have led to the elimination of certain GSS-API functions.

   Moreover, the JCA defines a provider model which allows for
   implementation independent access to security services. Using this
   model, applications can seamlessly switch between different
   implementations and dynamically add new services. The GSS-API
   specification leverages these concepts by the usage of providers for
   the mechanism implementations.

4.1.  Package Name

   The classes and interfaces defined in this document reside in the
   package called "org.ietf.jgss".  Applications that wish to make use
   of this API should import this package name as shown in section 7.

4.2.  Provider Framework

   The Java security API's use a provider architecture that allows
   applications to be implementation independent and security API
   implementations to be modular and extensible.  The



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


   java.security.Provider class is an abstract class that a vendor
   extends.  This class maps various properties that represent different
   security services that are available to the names of the actual
   vendor classes that implement those services.  When requesting a
   service, an application simply specifies the desired provider and the
   API delegates the request to service classes available from that
   provider.

   Using the Java security provider model insulates applications from
   implementation details of the services they wish to use.
   Applications can switch between providers easily and new providers
   can be added as needed, even at runtime.

   The GSS-API may use providers to find components for specific
   underlying security mechanisms.  For instance, a particular provider
   might contain components that will allow the GSS-API to support the
   Kerberos v5 mechanism and another might contain components to support
   the SPKM mechanism.  By delegating mechanism specific functionality
   to the components obtained from providers the GSS-API can be extended
   to support an arbitrary list of mechanism.

   How the GSS-API locates and queries these providers is beyond the
   scope of this document and is being deferred to a Service Provider
   Interface (SPI) specification.  The availability of such a SPI
   specification is not mandatory for the adoption of this API
   specification nor is it mandatory to use providers in the
   implementation of a GSS-API framework. However, by using the provider
   framework together with an SPI specification one can create an
   extensible and implementation independent GSS-API framework.

4.3.  Integer types

   All numeric values are declared as "int" primitive Java type.  The
   Java specification guarantees that this will be a 32 bit two's
   complement signed number.

   Throughout this API, the "boolean" primitive Java type is used
   wherever a boolean value is required or returned.

4.4.  Opaque Data types

   Java byte arrays are used to represent opaque data types which are
   consumed and produced by the GSS-API in the forms of tokens.  Java
   arrays contain a length field which enables the users to easily
   determine their size.  The language has automatic garbage collection
   which alleviates the need by developers to release memory and
   simplifies buffer ownership issues.




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


4.5.  Strings

   The String object will be used to represent all textual data.  The
   Java String object, transparently treats all characters as two-byte
   Unicode characters which allows support for many locals.  All
   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.