Java Java Generic Security Services and Kerberos（JDK8）

143 阅读 0 评论 0 点赞

Java Generic Security Services and Kerberos

Feature Enhancements Added to Java

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.

Java Generic Security Services API and Kerberos Enhancements for Java SE 8

The following enhancements were added to the Java GSS API and Kerberos implementation in Java SE 8.

MS-SFU Kerberos Extensions for JDK 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.)

MS-SFU Implementation Details

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.

Java Generic Security Services API and Kerberos Enhancements for Java SE 6

The following enhancements were added to the Java Generic Security Services API (Java GSS) and Kerberos implementation in Java SE 6.

Support for AES encryption type

Java SE 5.0 supports the DES and Triple DES encryption types, with the following aliases:

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.

The AES encryption type is specified in the Kerberos configuration file under the libdefaults section. It is specified as follows, with the 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 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.

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

Java SE 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 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.

The RC4-HMAC encryption type is specified in the Kerberos configuration file under the 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.
Support for SPNEGO in the Java GSS API

Java SE now supports SPNEGO mechanism in the Java GSS API.

The Java GSS API is a framework that can support multiple security mechanisms; however GSS-API does not prescribe the method by which 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 example, Java GSS applications specify the 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");

To select the 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. The 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 the SPNEGO authentication scheme in HTTP as well. Check the 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.

The Kerberos specification defines a framework for Kerberos pre-authentication mechanisms. The latest 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 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.
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 API and Kerberos Enhancements for Java SE 5.0

The following enhancements were added to the Java Generic Security Services API (Java GSS) and Kerberos implementation in Java SE 5.0.

Support for Triple DES encryption type
Prior to Java SE 5.0, only the DES encryption type was supported. Java SE 5.0 supports both DES and Triple DES encryption types. This improves interoperability of the Java SE Kerberos implementation with other Kerberos implementations, such as Solaris 10 and MIT Kerberos.
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-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 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.
IPv6 Support in Kerberos
Java SE now supports IPv6 addresses in Kerberos tickets. Prior to Java SE 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, 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.
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 section Kerberos Requirements 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 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.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 an explicit JAAS program, it can use any index name, including the ones listed previously.

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, then 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 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 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.
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, then 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 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.