Java Generic Security Services: (Java GSS) and Kerberos

Feature Enhancements added to Java

This page describes and lists security features and enhancements added to Java by major version number, from v1.4 through v6.

NOTE: The APIs and features described in this document are subject to change.

Java Generic Security Services (Java GSS) and Kerberos Enhancements for Java SE 6

The following enhancements were added to the Java GSS/Kerberos implementation in Java SE 6.

Support for AES encryption type

J2SE 5.0 supports DES and Triple DES encryption type, with following aliases:

des-cbc-md5 des-cbc-crc des3-cbc-sha1 Starting from Java SE 6, support for AES encryption type (AES128 and AES256) in Java GSS/Kerberos is available. This improves interoperability of the Java SE Kerberos implementation with other Kerberos implementations, such as Solaris 10 and MIT Kerberos.

AES encryption type is specified in the Kerberos configuration file under the libdefaults section. It is specified as follows, with following tags: default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes.

(AES128 encryption type)

aes128-cts aes128-cts-hmac-sha1-96 (AES256 encryption type)

aes256-cts aes256-cts-hmac-sha1-96 NOTE: The JCE framework within JDK includes an ability to enforce restrictions regarding the cryptographic algorithms and maximum cryptographic strengths available to applications. Such restrictions are specified in "jurisdiction policy files". The jurisdiction policy files bundled in Java SE limits the maximum key length. Hence, in order to use AES256 encryption type, you will need to install the JCE crypto policy with the unlimited version to allow AES with 256-bit key.

For example, the libdefaults section in the configuration file might include the following.

default_tkt_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc permitted_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc default_tkt_enctypes is used to specify the encryption types to use for the session key in the ticket-granting-ticket. It is used by the client to restrict the encryption types of session keys that will be used to communicate with the KDC. The default value is des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts .

default_tgs_enctypes is used to specify the encryption types to use for the session key in service tickets. It is used by the client to restrict the encryption types of session keys that are shared by the client and server. The default value is des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts.

permitted_enctypes is used to specify the encryption types permitted to be used by a service. It is used by the server to restrict the encryption types of session keys that it will accept. The default value is des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts.
Support for RC4-HMAC encryption type

J2SE 5.0 already supports DES and Triple DES encryption type, with following aliases:
des-cbc-md5 des-cbc-crc des3-cbc-sha1 Starting from Java SE 6, support for RC4-HMAC encryption type in Java GSS/Kerberos is available. This improves interoperability of the Java SE Kerberos implementation with other Kerberos implementations, such as Windows, Solaris 10 and MIT Kerberos. Windows Active Directoiory supports RC4-HMAC as the default Kerberos encryption type.

RC4-HMAC encryption type is specified in the Kerberos configuration file under the libdefaults section. It is specified as follows, with following tags: default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes.

rc4-hmac arcfour-hmac arcfour-hmac-md5 For example, the libdefaults section in the configuration file might include the following.

default_tkt_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc permitted_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc default_tkt_enctypes is used to specify the encryption types to use for the session key in the ticket-granting-ticket. It is used by the client to restrict the encryption types of session keys that will be used to communicate with the KDC. The default value is des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts

default_tgs_enctypes is used to specify the encryption types to use for the session key in service tickets. It is used by the client to restrict the encryption types of session keys that are shared by the client and server. The default value is des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts.

permitted_enctypes is used to specify the encryption types permitted to be used by a service. It is used by the server to restrict the encryption types of session keys that it will accept. The default value is des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts.
Support for SPNEGO in Java GSS

Java SE now supports SPNEGO mechanism in Java GSS.

Java GSS is a framework that can support multiple security mechanisms; however GSS-API does not prescribe the method by which GSS-API peers can establish whether they have a common security mechanism. The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism is a pseudo security mechanism that enables GSS-API peers to securely negotiate a common security mechanism to be used. The SPNEGO protocol is used to negotiate which security mechanism should be adopted.

Currently Java GSS applications specify a unique object identifier (OID) to select the underlying security mechanism. For e.g. Java GSS applications specify Kerberos mechanism OID "1.2.840.113554.1.2.2 to use Kerberos mechanism. Oid mechOid = new Oid("1.2.840.113554.1.2.2");

To select SPNEGO security mechanism, Java GSS applications would need to specify the SPNEGO mechanism OID "1.3.6.1.5.5.2". Oid mechOid = new Oid("1.3.6.1.5.5.2);

Support for SPNEGO improves interoperability with Microsoft products. SPNEGO protocol is heavily used to interoperate with Microsoft server over HTTP, to support HTTP-Based Cross-Platform Authentication via the Negotiate Protocol. Java SE now supports SPNEGO authentication scheme in HTTP as well. Please check list of new networking features for Java SE 6.
Support for new Pre-Authentication mechanisms

Java SE now includes support for the new pre-authentication mechanisms.

Kerberos is a protocol for verifying the identity of principals. The Kerberos protocol provides a mechanism called pre-authentication for proving the identity of a principal and for better protecting the long-term secret of the principal.

Kerberos specification defines a framework for Kerberos pre-authentication mechanisms. Lastest Kerberos specification defines new pre-authentication mechanisms to notify the client which key to use, salt updates, and other additional parameters. The new pre-authentication mechanisms indicate a requirement for additional pre-authentication.

With the support of new pre-authentication mechanisms, Java GSS/Kerberos client can now handle the salt value updates when required.
Native platform GSS integration

This feature allows Java applications to take advantage of features in native GSS implementation available on the platform. To enable Java GSS to delegate to the native GSS library and its list of native mechanisms, set the system property "sun.security.jgss.native" to true. When enabled, Java GSS would look for native GSS library using the operating system specific name, e.g. Solaris: libgss.so vs Linux: libgssapi.so. If the desired GSS library has a different name or is not located under a directory for system libraries, then its full path should be specified using the system property "sun.security.jgss.lib".

For Java SE 6, the native GSS support is limited to Solaris and Linux. Setting these system properties on platforms which native GSS integration is not supported will be ignored.

Unlike the default Java GSS implementation which relies on JAAS KerberosLoginModule for initial credential acquisition, when using native GSS, the initial credential should be acquired beforehand, e.g. kinit, prior to calling JGSS APIs.

In addition, when performing operations as a particular Subject, e.g. Subject.doAs(...) or Subject.doAsPrivileged(...), the to-be-used GSSCredential should be added to Subject's private credential set. Otherwise, the GSS operations will fail since no credential is found.
JAAS Login Entry Names Changes

The JAAS login entry names for both SunJSSE and JGSS are unified, and can be specified separately for different mechanisms. For Kerberos 5, the names are
```
com.sun.security.jgss.krb5.initiate
com.sun.security.jgss.krb5.accept
```

Java Generic Security Services (Java GSS) and Kerberos Enhancements for J2SE 5.0

The following enhancements were added to the Java GSS/Kerberos implementation in J2SE 5.0.

Support for Triple DES encryption type.
Prior to J2SE 5.0, only the DES encryption type was supported. J2SE 5.0 supports both DES and Triple DES encryption type. This improves interoperability of the Java SE Kerberos implementation with other Kerberos implementations, such as Solaris 10 and MIT Kerberos.
Triple DES encryption type is specified in the Kerberos configuration file under the "libdefaults" section. It is specified as "des3-cbc-sha1" with following tags: default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes. "dec3-cbc-sha1" has the following aliases:
```
des3-hmac-sha1
des3-cbc-sha1-kd
des3-cbc-hmac-sha1-kd
```
For example, the libdefaults section in the configuration file might include the following.
```
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes   = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
```
default_tkt_enctypes is used to specify the encryption types to use for the session key in the ticket-granting-ticket. It is used by the client to restrict the encryption types of session keys that will be used to communicate with the KDC. The default value is "des-cbc-md5 des-cbc-crc des3-cbc-sha1"
default_tgs_enctypes is used to specify the encryption types to use for the session key in service tickets. It is used by the client to restrict the encryption types of session keys that are shared by the client and server. The default value is "des-cbc-md5 des-cbc-crc des3-cbc-sha1".

permitted_enctypes is used to specify the encryption types permitted to be used by a service. It is used by the server to restrict the encryption types of session keys that it will accept. The default value is "des-cbc-md5 des-cbc-crc des3-cbc-sha1".
TCP vs. UDP Preference Configuration
Java SE now supports the use of the "udp_preference_limit" property in the Kerberos configuration file (krb5.conf).
When sending a message to the KDC, the Java SE Kerberos library will use TCP if the size of the message is above udp_preference_list. If the message is smaller than udp_preference_list, then UDP will be tried at most three times. If the KDC indicates that the request is too big, the Java SE Kerberos library will use TCP.
IPv6 Support in Kerberos
Java SE now supports IPv6 addresses in Kerberos tickets. Prior to J2SE 5, only IPv4 addresses were supported in tickets.
TGT Renewals
The Java Authentication and Authorizaton Server (JAAS) Kerberos login module in JDK 5.0, Krb5LoginModule, now supports Ticket Granting Ticket (TGT) renewal. This allows long-running services to renew their TGT automatically without user interaction or requiring the services to restart.
With this feature, if Krb5LoginModule obtains an expired ticket from the ticket cache, the TGT will be automatically renewed and be added to Subject of the caller who requested the ticket. If the ticket cannot be renewed for any reason, then Krb5LoginModule will use its configured callback handler to retrieve a username and password to acquire a new TGT.

To use this feature, configure Krb5LoginModule to use the ticket cache and set the newly introduced renewTGT option to true. Here is an example of a JAAS login configuration file that requests TGT renewal.
```
server {
  com.sun.security.auth.module.Krb5LoginModule required
        principal=principal@your_realm
        useTicketCache=true
        renewTGT=true;
};
```
Note that if renewTGT is set to true, then useTicketCache must also be set to true; otherwise, it results in a configuration error.
Login Entry Names for SunJSSE
In JDK 5.0, the SunJSSE provider has added support for the Kerberos cipher suites, as described in RFC 2712 and the What's New in JSSE in J2SE 5.0 in the JSSE Reference Guide. The following JAAS login configuration index names are reserved for this feature.
```
com.sun.net.ssl.server
com.sun.net.ssl.client
```
When a JSSE application uses the Kerberos cipher suites without explicit JAAS program, the SunJSSE provider will use these index names to find and configure the JAAS login module to acquire the necessary Kerberos credentials. For example, such an application might have the following JAAS configuration file.
```
 com.sun.net.ssl.server {
  com.sun.security.auth.module.Krb5LoginModule required
        principal=service_principal@your_realm
        useKeyTab=true
        keyTab=keytab_name
        storeKey=true;
};
```
If the entry is not found, the default "other" index name will be used. The service name for TLS is "host". For example, a TLS service running on a machine named "raven.example.com" in the realm named "KRBNT-OPERATIONS.EXAMPLE.COM" would have the service principal name
```
host/raven.example.com@KRBNT-OPERATIONS.EXAMPLE.COM
```
There are no restrictions on the TLS client; it may use any valid Kerberos principal name.
When a JSSE application uses the Kerberos cipher suites with explicit JAAS program, it can use any index name, including the ones listed above.

New Features in Java GSS for Java 2 SDK, Standard Edition, v 1.4.2

Configurable Kerberos Settings
The Kerberos Key Distribution Center (KDC) name and realm settings are provided in the Kerberos configuration file or via the system properties java.security.krb5.kdc and java.security.krb5.realm. In previous releases, changes to the Kerberos configuration values would only take effect when an application was restarted.
In the 1.4.2 release of the Java platform, a new boolean option refreshKrb5Config can be specified in the entry for Krb5LoginModule in the JAAS configuration file. If this option is set to true, the configuration values will be refreshed before the login method of the Krb5LoginModule is called.
Support for Slave Kerberos Key Distribution Center
Kerberos allows the use of slave KDCs so that if the master KDC is unavailable, the slave KDCs will respond to user requests. In earlier releases of the Java SE, Sun's implementation of Kerberos tried only the master KDC and would give up if there was no response within the default KDC timeout specified in the Kerberos configuration file, or 30 seconds if no timeout had been specified.
With this 1.4.2 release, Sun's implementation of Kerberos will retry with the slave KDC(s), if they are specified. The slave KDCs can be specified in the Kerberos configuration file or via a list of KDCs separated by a colon (:) in the system property java.security.krb5.kdc.
Support TCP for Kerberos Key Distribution Center Transport
Sun's implementation of Kerberos implements Kerberos version 5 according to RFC 1510 and uses UDP transport for ticket requests. A new Internet draft updates this RFC. One of the added features is required support for TCP as a transport in addition to UDP. As a result, in cases where Kerberos tickets exceed the UDP packet size limit, the KDC would return an error code indicating that the request should be resent over TCP.
In the current 1.4.2 release, Sun's implementation of Kerberos now supports automatic fallback to TCP. Therefore, if the Kerberos ticket request using UDP fails and the KDC returns the error code KRB_ERR_RESPONSE_TOO_BIG, TCP is automatically the default transport.
Kerberos Service Ticket in the Subject's Private Credentials
The Kerberos service ticket is now stored in the Subject's private credentials. This change allows application developers access to the service ticket so that it can be used outside the JGSS (for example, in native applications or for proprietary uses). In addition, the service ticket can now be reused if the application tries to establish a security context to the same service again. The service ticket should be valid for it to be reusable.
Previously, when using Java Generic Security Services (JGSS) over Kerberos V5, if the useSubjectCredsOnly property was set to true, the Ticket Granting Ticket (TGT) was retrieved from the Subject and used to establish a GSS Security context. The service ticket obtained was not stored in the Subject. Now the service ticket is also stored in the Subject if useSubjectCredsOnly is true.

If a client application searches through the Subject's private credentials, in previous releases it would find only the TGT. As of this release, it also will find any Service ticket(s) obtained.

The bug report associated with this change is 4688866.