RFC 8353
Generic Security Service API Version 2: Java Bindings Update
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
Java security APIs use a provider architecture that allows applications to be implementation independent and security API implementations to be modular and extensible. The 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 [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 mechanisms.
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 the "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 object.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., "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 object. 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 [RFC2743], 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 [RFC2744]: 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 of a 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,
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,
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 a GSSCredential object representing a specific
identity.
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 and might not match the initiator-requested values. If any
retrieved attribute does not match the desired value but it is
necessary for the application protocol, the application SHOULD
destroy the security context and not use it for application traffic.
Otherwise, 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 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.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 a 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 [RFC2743] defined the usage of major and minor status values for the signaling of GSS-API errors. The major code, also called the 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 gss_display_status. A GSSException object MAY also include an output token that SHOULD be sent to the peer. If an exception is thrown during context establishment, the context negotiation has failed and the GSSContext object MUST be abandoned. If it is thrown in a per-message call, the context MAY remain useful.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 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 codes:
Table: GSS Status Codes +----------------------+-------+------------------------------------+ | Name | Value | Meaning | +----------------------+-------+------------------------------------+ | BAD_BINDINGS | 1 | Incorrect channel bindings were | | | | supplied. | | 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 | | | | supplied. | | BAD_MIC | 6 | A token had an invalid MIC. | | CONTEXT_EXPIRED | 7 | The context has expired. | | CREDENTIALS_EXPIRED | 8 | The referenced credentials have | | | | expired. | | DEFECTIVE_CREDENTIAL | 9 | A supplied credential was invalid. | | DEFECTIVE_TOKEN | 10 | A supplied token was invalid. | | FAILURE | 11 | Miscellaneous failure, unspecified | | | | at the GSS-API level. | | NO_CONTEXT | 12 | Invalid context has been supplied. | | 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 | | | | unavailable. | | 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: +-----------------+-------+-----------------------------------------+ | Name | Value | Meaning | +-----------------+-------+-----------------------------------------+ | DUPLICATE_TOKEN | 19 | The token was a duplicate of an earlier | | | | version. | | OLD_TOKEN | 20 | The token's validity period has | | | | expired. | | UNSEQ_TOKEN | 21 | A later token has already been | | | | processed. | | GAP_TOKEN | 22 | The expected token was not received. | +-----------------+-------+-----------------------------------------+ 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 [RFC2743].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 expired. | | isUnseqToken | A later token has already been processed. | | 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
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 to allow support for multiple
syntaxes for each supported namespace and to allow 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, the
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 the
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 the GSSContext
interface's getSrcName and getTargName methods 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 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. However, applications SHOULD note that to avoid surprising behavior, it is best to ensure that the names being compared are either both mechanism names for the same mechanism or both internal names that are not mechanism names. This holds whether the equals method is used directly or the export method is used to generate byte strings that are then compared byte-by-byte. 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 an 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 [RFC2743]. 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 determines 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 context. Channel bindings are communicated to the GSS-API using the ChannelBinding object. The application MAY use byte arrays as well as instances of InetAddress to specify the application data to be used in the channel binding. 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. 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.
(page 28 continued on part 3)
