This page describes and lists security features and enhancements added to the Java Generic Security Services API (Java GSS) and Kerberos, by major version number, from v1.4 through v1.8.
NOTE: The APIs and features described in this document are subject to change.
The following enhancements were added to the Java GSS API and Kerberos implementation in Java SE 8.
MS-SFU refers to Microsoft Kerberos 5 extensions that allow a service to obtain a Kerberos service ticket on behalf of a client. This is useful when the authentication between the client and this service is not established through Kerberos (thus the standard Kerberos delegation cannot be used) but the service needs to access a Kerberos-secured back-end server in the name of the client.
Support for the MS-SFU extensions was added in JDK 8. This includes support for the S4U2self and S4U2proxy protocols, as defined in MS-SFU.
This feature is very useful in secure enterprise deployments. For example, in a typical network service, the front end (such as a web server) often needs to access the back end (such as a database server) on behalf of a client. Normal Kerberos 5 supports delegation, but demands that all layers in this chain explicitly use Kerberos authentication at each step, which is not always possible or desirable.
For example, if a client logs in to a web server using digest authentication, then there are no Kerberos credentials to be delegated, and normal step-by-step Kerberos 5 authentication cannot occur. However, because MS-SFU defines the Service for User (S4U2self) extension so that the front end can access the back end on behalf of the client without presenting the client's Kerberos credentials, MS-SFU could provide authentication in this situation.
In addition, there are potential security gaps in the standard Kerberos 5 delegation mechanism (which Microsoft calls open delegation). In this mechanism, once the service account has the client's delegated credentials, it has access to any service. Thus, great care is needed with open delegation.
In contrast, the MS-SFU delegation (implemented in S4U2proxy) is much more secure. Here the administrator can precisely control the services to which a particular service can delegate. (Microsoft calls this constrained delegation.)
The original Kerberos 5 protocol was defined in RFC 4120. MS-SFU adds two extensions to that protocol: Service for User to Self (S4U2self), which allows a front-end service to obtain a Kerberos service ticket to itself on behalf of a user, and Service for User to Proxy (S4U2proxy), which enables it to obtain a service ticket on behalf of the user to a second, back-end service.
Together, these two extensions enable the front-end service to obtain a Kerberos service ticket on behalf of a user. The resulting service ticket can be used to access other services on the local or remote machines.
A new public method (GSSCredential::impersonate
)
has been added to the com.sun.security.jgss
package to
implement these extensions.
The following enhancements were added to the Java Generic Security Services API (Java GSS) and Kerberos implementation in Java SE 6.
des-cbc-md5
des-cbc-crc
des3-cbc-sha1
Starting from Java SE 6, support for the AES
encryption type (AES128 and AES256Triple DES encryption type is
specified ) 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.libdefaults
section. It is specified as
follows, with the following tags: default_tkt_enctypes,
default_tgs_enctypes, permitted_enctypes.
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
limit the maximum key length. Hence, to use the AES256 encryption
type, you will need to install the JCE crypto policy with the
unlimited version to allow AES with 256-bit key.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
.des-cbc-md5
des-cbc-crc
des3-cbc-sha1
Starting from Java SE 6, support for the 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 Directory supports RC4-HMAC as the default
Kerberos encryption type.libdefaults
section. It
is specified as follows, with the 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
.OID
"1.2.840.113554.1.2.2
to use the Kerberos mechanism. This
would be coded as follows:Oid mechOid = new Oid("1.2.840.113554.1.2.2");
OID
"1.3.6.1.5.5.2".
Oid mechOid = new
Oid("1.3.6.1.5.5.2);
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 a native GSS library using the operating system-specific name. For example, for Solaris, libgss.so or for 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, native GSS support is limited to Solaris and Linux. Setting these system properties on platforms where native GSS integration is not supported will be ignored.
Unlike the default Java GSS implementation, which relies on the JAAS KerberosLoginModule for initial credential acquisition, when using native GSS, the initial credential should be acquired beforehand. That is, call kinit prior to calling JGSS APIs.
In addition, when performing operations as a particular Subject,
for example, 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.
com.sun.security.jgss.krb5.initiate com.sun.security.jgss.krb5.accept
The following enhancements were added to the Java Generic Security Services API (Java GSS) and Kerberos implementation in Java SE 5.0.
The Triple DES encryption type is specified in the Kerberos configuration file under the "libdefaults" section. It is specified as "des3-cbc-sha1" with the 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-kdFor 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-crcdefault_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".
When sending a message to the KDC, the Java SE Kerberos library will use TCP if the size of the message is larger than 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.
With this feature, if Krb5LoginModule obtains an expired ticket from the ticket cache, then 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.
com.sun.net.ssl.server com.sun.net.ssl.clientWhen a JSSE application uses the Kerberos cipher suites without an 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, then 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.COMThere 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 an explicit JAAS program, it can use any index name, including the ones listed previously.
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
, then the configuration
values will be refreshed before the login
method of
the Krb5LoginModule
is called.
With this 1.4.2 release, Sun's implementation of Kerberos will
retry with the slave KDCs, 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
.
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
, then TCP is automatically
the default transport.
Previously, when using Java Generic Security Services API (JGSS)
over Kerberos V5, if the
useSubjectCredsOnly
property was set to true,
then 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 tickets obtained.
The bug report associated with this change is 4688866.