Tech-invite   World Map
3GPPspecs     Glossaries     IETF     RFCs     Groups     SIP     ABNFs

RFC 5653


Generic Security Service API Version 2: Java Bindings Update

Part 2 of 5, p. 15 to 32
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 15 
5.  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 that 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.

5.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 8.

5.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 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

   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 [RFC4121] and another might contain components
   to support the Simple Public-Key GSS-API Mechanism (SPKM) [RFC2025].
   By delegating mechanism-specific functionality to the components
   obtained from providers, the GSS-API can be extended to support an
   arbitrary list of mechanism.

Top      Up      ToC       Page 16 
   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 an 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.

5.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.

5.4.  Opaque Data Types

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

5.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

5.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., "") as
   well as from its ASN.1 DER encoding.  Methods are also provided to
   test equality and provide the DER representation for the object.

Top      Up      ToC       Page 17 
   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.

5.7.  Object Identifier Sets

   The Java bindings represent object identifier 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 [GSSAPIv2-
   UPDATE], the Oid class includes a method that 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 memory management issues of
   the C counterpart.

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

5.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

Top      Up      ToC       Page 18 
      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 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;

   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.

   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,

Top      Up      ToC       Page 19 
   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

5.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 that 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.

5.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

Top      Up      ToC       Page 20 
   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 that allow the caller to supply input and
   output streams that will be used for the reading and writing of the
   token data.

5.11.  Inter-Process 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 inter-process 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 inter-process
   tokens are protected in transit, and transferred only to processes
   that are trustworthy.  An inter-process token is represented using a
   byte array emitted from the export method of the GSSContext
   interface.  The receiver of the inter-process 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.

5.12.  Error Reporting

   RFC 2743 [GSSAPIv2-UPDATE] defined the usage of major and minor
   status values for the 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.  The GSSException class
   also contains methods to obtain textual representations for both the
   major and minor values, which is equivalent to the functionality of

Top      Up      ToC       Page 21 
5.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.

   A GSSException object, along with providing the functionality for
   setting of the various error codes and translating them into textual
   representation, also contains the definitions of all the numeric
   error values.  The following table lists the definitions of error

      Table: GSS Status Codes

      Name                   Value   Meaning

      BAD_BINDINGS             1     Incorrect channel bindings were

      BAD_MECH                 2     An unsupported mechanism
                                     was requested.

      BAD_NAME                 3     An invalid name was supplied.

      BAD_NAMETYPE             4     A supplied name was of an
                                     unsupported type.

      BAD_STATUS               5     An invalid status code was

      BAD_MIC                  6     A token had an invalid MIC.

      CONTEXT_EXPIRED          7     The context has expired.

Top      Up      ToC       Page 22 
      CREDENTIALS_EXPIRED      8     The referenced credentials
                                     have expired.

      DEFECTIVE_CREDENTIAL     9     A supplied credential was

      DEFECTIVE_TOKEN         10     A supplied token was invalid.

      FAILURE                 11     Miscellaneous failure,
                                     unspecified at the GSS-API

      NO_CONTEXT              12     Invalid context has been

      NO_CRED                 13     No credentials were supplied, or
                                     the credentials were unavailable
                                     or inaccessible.

      BAD_QOP                 14     The quality-of-protection (QOP)
                                     requested could not be provided.

      UNAUTHORIZED            15     The operation is forbidden by
                                     the local security policy.

      UNAVAILABLE             16     The operation or option is

      DUPLICATE_ELEMENT       17     The requested credential
                                     element already exists.

      NAME_NOT_MN             18     The provided name was not a
                                     mechanism name.

      The following four status codes (DUPLICATE_TOKEN, OLD_TOKEN,
      UNSEQ_TOKEN, and GAP_TOKEN) are contained in a GSSException
      only if detected during context establishment, in which case it
      is a fatal error. (During per-message calls, these values are
      indicated as supplementary information contained in the
      MessageProp object.) They are:

      DUPLICATE_TOKEN         19     The token was a duplicate of an
                                     earlier version.

      OLD_TOKEN               20     The token's validity period has

Top      Up      ToC       Page 23 
      UNSEQ_TOKEN             21     A later token has already been

      GAP_TOKEN               22     The expected token was not

   The GSS major status code of FAILURE is used to indicate that the
   underlying mechanism detected an error for which no specific GSS
   status code is defined.  The mechanism-specific status code can
   provide more details about the error.

   The different major status codes that can be contained in the
   GSSException object thrown by the methods in this specification are
   the same as the major status codes returned by the corresponding
   calls in RFC 2743 [GSSAPIv2-UPDATE].

5.12.2.  Mechanism-Specific Status Codes

   Mechanism-specific status codes are communicated in two ways, they
   are part of any GSSException thrown from the mechanism-specific layer
   to signal a fatal error, or they are part of the MessageProp object
   that the per-message calls use to signal non-fatal errors.

   A default value of 0 in either the GSSException object or the
   MessageProp object will be used to represent the absence of any
   mechanism-specific status code.

5.12.3.  Supplementary Status Codes

   Supplementary status codes are confined to the per-message methods of
   the GSSContext interface.  Because of the informative nature of these
   errors it is not appropriate to use exceptions to signal them.
   Instead, the per-message operations of the GSSContext interface
   return these values in a MessageProp object.

   The MessageProp class defines query methods that return boolean
   values indicating the following supplementary states:

      Table: Supplementary Status Methods

      Method Name        Meaning when "true" is returned

      isDuplicateToken   The token was a duplicate of an
                         earlier token.

      isOldToken         The token's validity period has

Top      Up      ToC       Page 24 
      isUnseqToken       A later token has already been

      isGapToken         An expected per-message token was
                         not received.

   A "true" return value for any of the above methods indicates that the
   token exhibited the specified property.  The application must
   determine the appropriate course of action for these supplementary
   values.  They are not treated as errors by the GSS-API.

5.13.  Names

   A name is used to identify a person or entity.  GSS-API authenticates
   the relationship between a name and the entity claiming the name.

   Since different authentication mechanisms may employ different
   namespaces for identifying their principals, GSS-API's naming support
   is necessarily complex in multi-mechanism environments (or even in
   some single-mechanism environments where the underlying mechanism
   supports multiple namespaces).

   Two distinct conceptual representations are defined for names:

   1) A GSS-API form represented by implementations of the GSSName
      interface: A single GSSName object may contain multiple names from
      different namespaces, but all names should refer to the same
      entity.  An example of such an internal name would be the name
      returned from a call to the getName method of the GSSCredential
      interface, when applied to a credential containing credential
      elements for multiple authentication mechanisms employing
      different namespaces.  This GSSName object will contain a distinct
      name for the entity for each authentication mechanism.

      For GSS-API implementations supporting multiple namespaces,
      GSSName implementations must contain sufficient information to
      determine the namespace to which each primitive name belongs.

   2) Mechanism-specific contiguous byte array and string forms:
      Different GSSName initialization methods are provided to handle
      both byte array and string formats and to accommodate various
      calling applications and name types.  These formats are capable of
      containing only a single name (from a single namespace).
      Contiguous string names are always accompanied by an object
      identifier specifying the namespace to which the name belongs, and
      their format is dependent on the authentication mechanism that
      employs that name.  The string name forms are assumed to be
      printable, and may therefore be used by GSS-API applications for

Top      Up      ToC       Page 25 
      communication with their users.  The byte array name formats are
      assumed to be in non-printable formats (e.g., the byte array
      returned from the export method of the GSSName interface).

   A GSSName object can be converted to a contiguous representation by
   using the toString method.  This will guarantee that the name will be
   converted to a printable format.  Different initialization methods in
   the GSSName interface are defined allowing support for multiple
   syntaxes for each supported namespace, and allowing users the freedom
   to choose a preferred name representation.  The toString method
   should use an implementation-chosen printable syntax for each
   supported name type.  To obtain the printable name type,
   getStringNameType method can be used.

   There is no guarantee that calling the toString method on the GSSName
   interface will produce the same string form as the original imported
   string name.  Furthermore, it is possible that the name was not even
   constructed from a string representation.  The same applies to
   namespace identifiers, which may not necessarily survive unchanged
   after a journey through the internal name form.  An example of this
   might be a mechanism that authenticates X.500 names, but provides an
   algorithmic mapping of Internet DNS names into X.500.  That
   mechanism's implementation of GSSName might, when presented with a
   DNS name, generate an internal name that contained both the original
   DNS name and the equivalent X.500 name.  Alternatively, it might only
   store the X.500 name.  In the latter case, the toString method of
   GSSName would most likely generate a printable X.500 name, rather
   than the original DNS name.

   The context acceptor can obtain a GSSName object representing the
   entity performing the context initiation (through the usage of
   getSrcName method).  Since this name has been authenticated by a
   single mechanism, it contains only a single name (even if the
   internal name presented by the context initiator to the GSSContext
   object had multiple components).  Such names are termed internal-
   mechanism names (or MNs), and the names emitted by GSSContext
   interface in the getSrcName and getTargName are always of this type.
   Since some applications may require MNs without wanting to incur the
   overhead of an authentication operation, creation methods are
   provided that take not only the name buffer and name type, but also
   the mechanism oid for which this name should be created.  When
   dealing with an existing GSSName object, the canonicalize method may
   be invoked to convert a general internal name into an MN.

   GSSName objects can be compared using their equal method, which
   returns "true" if the two names being compared refer to the same
   entity.  This is the preferred way to perform name comparisons
   instead of using the printable names that a given GSS-API

Top      Up      ToC       Page 26 
   implementation may support.  Since GSS-API assumes that all primitive
   names contained within a given internal name refer to the same
   entity, equal can return "true" if the two names have at least one
   primitive name in common.  If the implementation embodies knowledge
   of equivalence relationships between names taken from different
   namespaces, this knowledge may also allow successful comparisons of
   internal names containing no overlapping primitive elements.

   When used in large access control lists, the overhead of creating a
   GSSName object on each name and invoking the equal method on each
   name from the Access Control List (ACL) may be prohibitive.  As an
   alternative way of supporting this case, GSS-API defines a special
   form of the contiguous byte array name, which may be compared
   directly (byte by byte).  Contiguous names suitable for comparison
   are generated by the export method.  Exported names may be re-
   imported by using the byte array constructor and specifying the
   NT_EXPORT_NAME as the name type object identifier.  The resulting
   GSSName name will also be a MN.

   The GSSName interface defines public static Oid objects representing
   the standard name types.  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.  Detailed description of the format is
   specified in the language-independent GSS-API specification

   Note that the results obtained by using the equals method will in
   general be different from those obtained by invoking canonicalize and
   export, and then comparing the byte array output.  The first series
   of operation 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 results only for MNs.

   It is important to note that the above are guidelines as to how
   GSSName implementations should behave, and are not intended to be
   specific requirements of how name objects must be implemented.  The
   mechanism designers are free to decide on the details of their
   implementations of the GSSName interface as long as the behavior
   satisfies the above guidelines.

5.14.  Channel Bindings

   GSS-API supports the use of user-specified tags to identify a given
   context to the peer application.  These tags are intended to be used
   to identify the particular communications channel that carries the

Top      Up      ToC       Page 27 
   context.  Channel bindings are communicated to the GSS-API using the
   ChannelBinding object.  The application may use byte arrays to
   specify the application data to be used in the channel binding as
   well as using instances of the InetAddress.  The InetAddress for the
   initiator and/or acceptor can be used within an instance of a
   ChannelBinding.  ChannelBinding can be set for the GSSContext object
   using the setChannelBinding method before the first call to init or
   accept has been performed.  Unless the setChannelBinding method has
   been used to set the ChannelBinding for a GSSContext object, "null"
   ChannelBinding will be assumed.  InetAddress is currently the only
   address type defined within the Java platform and as such, it is the
   only one supported within the ChannelBinding class.  Applications
   that use other types of addresses can include them as part of the
   application-specific data.

   Conceptually, the GSS-API concatenates the initiator and acceptor
   address information, and the application-supplied byte array to form
   an octet-string.  The mechanism calculates a Message Integrity Code
   (MIC) over this octet-string and binds the MIC to the context
   establishment token emitted by the init method of the GSSContext
   interface.  The same bindings are set by the context acceptor for its
   GSSContext object and during processing of the accept method, a MIC
   is calculated in the same way.  The calculated MIC is compared with
   that found in the token, and if the MICs differ, accept will throw a
   GSSException with the major code set to BAD_BINDINGS, and the context
   will not be established.  Some mechanisms may include the actual
   channel binding data in the token (rather than just a MIC);
   applications should therefore not use confidential data as channel-
   binding components.

   Individual mechanisms may impose additional constraints on addresses
   that may appear in channel bindings.  For example, a mechanism may
   verify that the initiator address field of the channel binding
   contains the correct network address of the host system.  Portable
   applications should therefore ensure that they either provide correct
   information for the address fields, or omit the setting of the
   addressing information.

5.15.  Stream Objects

   The context object provides overloaded methods that use input and
   output streams as the means to convey authentication and per-message
   GSS-API tokens.  It is important to note that the streams are
   expected to contain the usual GSS-API tokens, which would otherwise
   be handled through the usage of byte arrays.  The tokens are expected
   to have a definite start and an end.  The callers are responsible for

Top      Up      ToC       Page 28 
   ensuring that the supplied streams will not block, or expect to block
   until a full token is processed by the GSS-API method.  Only a single
   GSS-API token will be processed per invocation of the stream-based

   The usage of streams allows the callers to have control and
   management of the supplied buffers.  Because streams are non-
   primitive objects, the callers can make the streams as complicated or
   as simple as desired simply by using the streams defined in the package or creating their own through the use of inheritance.
   This will allow for the application's greatest flexibility.

5.16.  Optional Parameters

   Whenever the application wishes to omit an optional parameter the
   "null" value shall be used.  The detailed method descriptions
   indicate which parameters are optional.  Method overloading has also
   been used as a technique to indicate default parameters.

6.  Introduction to GSS-API Classes and Interfaces

   This section presents a brief description of the classes and
   interfaces that constitute the GSS-API.  The implementations of these
   are obtained from the CLASSPATH defined by the application.  If Java
   GSS becomes part of the standard Java APIs, then these classes will
   be available by default on all systems as part of the JRE's system

   This section also shows the corresponding RFC 2743 [GSSAPIv2-UPDATE]
   functionality implemented by each of the classes.  Detailed
   description of these classes and their methods is presented in
   section 7.

6.1.  GSSManager Class

   This abstract class serves as a factory to instantiate
   implementations of the GSS-API interfaces and also provides methods
   to make queries about underlying security mechanisms.

   A default implementation can be obtained using the static method
   getInstance().  Applications that desire to provide their own
   implementation of the GSSManager class can simply extend the abstract
   class themselves.

   This class contains equivalents of the following RFC 2743 [GSSAPIv2-
   UPDATE] routines:

Top      Up      ToC       Page 29 
      RFC 2743 Routine             Function                   Section(s)

      gss_import_name              Create an internal name from  7.1.6-
                                   the supplied information.     7.1.9

      gss_acquire_cred             Acquire credential            7.1.10-
                                   for use.                      7.1.12

      gss_import_sec_context       Create a previously exported  7.1.15

      gss_indicate_mechs           List the mechanisms           7.1.3
                                   supported by this GSS-API

      gss_inquire_mechs_for_name   List the mechanisms           7.1.5
                                   supporting the
                                   specified name type.

      gss_inquire_names_for_mech   List the name types           7.1.4
                                   supported by the
                                   specified mechanism.

6.2.  GSSName Interface

   GSS-API names are represented in the Java bindings through the
   GSSName interface.  Different name formats and their definitions are
   identified with Universal Object Identifiers (oids).  The format of
   the names can be derived based on the unique oid of each name type.
   The following GSS-API routines are provided by the GSSName interface:

      RFC 2743 Routine        Function                       Section(s)

      gss_display_name        Covert internal name             7.2.7
                              representation to text format.

      gss_compare_name        Compare two internal names.      7.2.3,

      gss_release_name        Release resources associated     N/A
                              with the internal name.

      gss_canonicalize_name   Convert an internal name to a    7.2.5
                              mechanism name.

      gss_export_name         Convert a mechanism name to      7.2.6
                              export format.

Top      Up      ToC       Page 30 
      gss_duplicate_name      Create a copy of the internal    N/A

   The gss_release_name call is not provided as Java does its own
   garbage collection.  The gss_duplicate_name call is also redundant;
   the GSSName interface has no mutator methods that can change the
   state of the object so it is safe for sharing across threads.

6.3.  GSSCredential Interface

   The GSSCredential interface is responsible for the encapsulation of
   GSS-API credentials.  Credentials identify a single entity and
   provide the necessary cryptographic information to enable the
   creation of a context on behalf of that entity.  A single credential
   may contain multiple mechanism-specific credentials, each referred to
   as a credential element.  The GSSCredential interface provides the
   functionality of the following GSS-API routines:

      RFC 2743 Routine           Function                    Section(s)

      gss_add_cred               Constructs credentials        7.3.12

      gss_inquire_cred           Obtain information about      7.3.4-
                                 credential.                   7.3.11

      gss_inquire_cred_by_mech   Obtain per-mechanism          7.3.5-
                                 information about             7.3.10
                                 a credential.

      gss_release_cred           Dispose of credentials        7.3.3
                                 after use.

6.4.  GSSContext Interface

   This interface encapsulates the functionality of context-level calls
   required for security context establishment and management between
   peers as well as the per-message services offered to applications.  A
   context is established between a pair of peers and allows the usage
   of security services on a per-message basis on application data.  It
   is created over a single security mechanism.  The GSSContext
   interface provides the functionality of the following GSS-API

      RFC 2743 Routine         Function                       Section(s)

      gss_init_sec_context     Initiate the creation of a       7.4.3-
                               security context with a peer.    7.4.6

Top      Up      ToC       Page 31 
      gss_accept_sec_context   Accept a security context        7.4.7-
                               initiated by a peer.             7.4.10

      gss_delete_sec_context   Destroy a security context.      7.4.12

      gss_context_time         Obtain remaining context         7.4.41

      gss_inquire_context      Obtain context                   7.4.32-
                               characteristics.                 7.4.46

      gss_wrap_size_limit      Determine token-size limit       7.4.13
                               for gss_wrap.

      gss_export_sec_context   Transfer security context        7.4.22
                               to another process.

      gss_get_mic              Calculate a cryptographic        7.4.18,
                               Message Integrity Code (MIC)     7.4.19
                               for a message.

      gss_verify_mic           Verify integrity on a received   7.4.20,
                               message.                         7.4.21

      gss_wrap                 Attach a MIC to a message and    7.4.14,
                               optionally encrypt the message   7.4.15

      gss_unwrap               Obtain a previously wrapped      7.4.16,
                               application message verifying    7.4.17
                               its integrity and optionally
                               decrypting it.

   The functionality offered by the gss_process_context_token routine
   has not been included in the Java bindings specification.  The
   corresponding functionality of gss_delete_sec_context has also been
   modified to not return any peer tokens.  This has been proposed in
   accordance to the recommendations stated in RFC 2743 [GSSAPIv2-
   UPDATE].  GSSContext does offer the functionality of destroying the
   locally stored context information.

6.5.  MessageProp Class

   This helper class is used in the per-message operations on the
   context.  An instance of this class is created by the application and
   then passed into the per-message calls.  In some cases, the
   application conveys information to the GSS-API implementation through

Top      Up      ToC       Page 32 
   this object and in other cases the GSS-API returns information to the
   application by setting it in this object.  See the description of the
   per-message operations wrap, unwrap, getMIC, and verifyMIC in the
   GSSContext interfaces for details.

6.6.  GSSException Class

   Exceptions are used in the Java bindings to signal fatal errors to
   the calling applications.  This replaces the major and minor codes
   used in the C-bindings specification as a method of signaling
   failures.  The GSSException class handles both minor and major codes,
   as well as their translation into textual representation.  All GSS-
   API methods are declared as throwing this exception.

      RFC 2743 Routine     Function                  Section

      gss_display_status   Retrieve textual          7.8.5, 7.8.6,
                           representation of error   7.8.8, 7.8.9

6.7.  Oid Class

   This utility class is used to represent Universal Object Identifiers
   and their associated operations.  GSS-API uses object identifiers to
   distinguish between security mechanisms and name types.  This class,
   aside from being used whenever an object identifier is needed,
   implements the following GSS-API functionality:

      RFC 2743 Routine          Function                         Section

      gss_test_oid_set_member   Determine if the specified oid   7.7.5
                                is part of a set of oids.

6.8.  ChannelBinding Class

   An instance of this class is used to specify channel binding
   information to the GSSContext object before the start of a security
   context establishment.  The application may use a byte array to
   specify application data to be used in the channel binding as well as
   to use instances of the InetAddress.  InetAddress is currently the
   only address type defined within the Java platform and as such, it is
   the only one supported within the ChannelBinding class.  Applications
   that use other types of addresses can include them as part of the
   application data.

Next RFC Part