| # Java Generic Security Services (Java GSS) and Kerberos ## Feature Enhancements added to JavaTM | Security Contents

This page describes and lists security features and enhancements added to JavaTM 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 JavaTM 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.abc.com" in the realm named "KRBNT-OPERATIONS.ABC.COM" would have the service principal name

  >     host/raven.abc.com@KRBNT-OPERATIONS.ABC.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 JavaTM GSS for Java TM 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.

Copyright © 1995-2006 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: java-security@sun.com. | Java Software