Compatibility Risk Description:To mitigate the risk introduced by the change of behavior in the Kerberos client (which announces RFC 6806 support when sending AS-REQ or TGS-REQ requests to a server), the following measures were introduced: 1) sun.security.krb5.disableReferrals system property can be used to completely disable the feature, and 2) the client will retry the connection without announcing support of RFC 6806 upon a server failure.
To mitigate the risk introduced by the change of behavior in the Kerberos client (which announces RFC 6806 support when sending AS-REQ or TGS-REQ requests to a server), the following measures were introduced: 1) sun.security.krb5.disableReferrals system property can be used to completely disable the feature, and 2) the client will retry the connection without announcing support of RFC 6806 upon a server failure.
Original CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8223172
11u CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8230496
Differences with 11u CSR: none
Note : Please note that A KRB_NT_ENTERPRISE public static field is not added to javax.security.auth.kerberos.KerberosPrincipal class as in original CSR.
Add support for Kerberos principal name canonicalization and cross-realm referrals as described by RFC 6806 protocol extension.
The Kerberos client does not support RFC 6806 principal name canonicalization nor cross-realm referrals in Authentication Service (AS) and Ticket-Granting Service (TGS) protocols. As a consequence, it cannot take advantage of more dynamic environment configurations and need to know (in advanced) how to reach the realm of the target principal (user or service).
Implement RFC 6068 on top of the, already supported, RFC 4120 cross-realm referrals feature. The Kerberos client will announce support of RFC 6068 when sending AS-REQ and TGS-REQ requests to a server. If the server supports RFC 6068, both parties will proceed as defined in the referred document. If the server does not support RFC 6068, the client announcement should be ignored. In cases in which the server sends an error after -and, probably, as a consequence-of- the announcement, the client will retry without claiming support of RFC 6068. This latter scheme acts as a backward compatibility fallback and mitigates the risk of changing the previous client behavior.
Client (AS-REQ) and server (TGS-REQ) referrals
When issuing AS-REQ and TGS-REQ requests, the Kerberos client sets the canonicalize option to announce support of RFC 6068 client and server referrals respectively.
If a KDC_ERR_WRONG_REALM is received in response to a AS-REQ, and the number of requests currently issued is below the limit (see sun.security.krb5.maxReferrals system property below), the client issues a new request to the referred realm.
If a referral TGT is received in response to a TGS-REQ, and the number of requests currently issued is below the limit (see sun.security.krb5.maxReferrals system property below), the client issues a new request to the referred realm. The TGT referral ticket is sent as part of the new request.
If a server error is received after a AS-REQ or TGS-REQ is sent, the client retries without setting the canonicalize option and announcing support of RFC 6068. The cross-referrals feature will be temporary disabled throughout the communication. This is a backward compatibility fallback mode.
capaths and domain_realm configurations
Previous to RFC 6806 cross-realm referrals implementation, capaths configuration and the DNS hierarchy were used to statically or heuristically obtain a cross-realm TGT. A cross-realm TGT belongs to the same realm than the target principal and can be used to finally obtain the corresponding TGS. This is described by RFC 4120 (section 1.2. Cross-Realm Operation) and still holds true after RFC 6806.
The difference with RFC 6806 is that upon receiving a dynamic-referral (as a result of any request), the next request targets the referred realm and is no longer a RFC 4120 cross-realm operation. In other words, service realm for the next request matches the one in the credentials that will be used (which are the referral-TGT previously received).
domain_realm configuration is used to map DNS names to realms. When creating a service principal without a realm, this map is used to determine its realm. This map may also be used to find the default realm for the local host. A service principal realm is used in the first place when requesting a ticket. Cross-realm referrals may be followed afterwards.
Enterprise Principal Name Type
NT-ENTERPRISE principals are supported by the client library. When issuing a AS-REQ request with a NT-ENTERPRISE principal, canonicalize option turns mandatory.
Principal name changes are allowed in AS-REQ responses only if 1) canonicalize option was set in the AS-REQ request, 2) PA-REQ-ENC-PA-REP pre-authentication data was sent in the AS-REQ response (meaning the server supports RFC 6068 FAST scheme) and 3) the authenticated checksum is correct.
Principal name changes are allowed in TGS-REQ responses only if 1) canonicalize option was set in the TGS-REQ request, and 2) sname has a referral value of the form krbtgt/TO-REALM.COM@FROM-REALM.COM.
Principal name changes are NOT allowed in other cases and a KRB_AP_ERR_MODIFIED exception is thrown.
TGT referral tickets (received in response to TGS-REQ requests) are saved in a in-memory cache until they expire. When a TGS-REQ request is issued, the cache is scrutinized. If a TGT referral ticket is available, it's used instead of sending a new request. As suggested by RFC 6806, this minimizes the network traffic and speeds up the process.
If a loop is introduced when adding a new referral TGT to the cache, the loop is broken by removing the next referred TGT.
Adding a TGT referral ticket to the cache may override a previous one, under the assumption that newer information is more accurate.
PA-REQ-ENC-PA-REP pre-authentication data is sent in AS-REQ requests and responses are verified as previously described (see Name canonicalization). PA-REQ-ENC-PA-REP pre-authentication data is sent for TGS-REQ requests but response verification is not enforced for compatibility reasons.
JDK crucible review link : https://java.se.oracle.com/code/cru/CR-JDK8UCPU-985
The following Security and System properties are introduced:
sun.security.krb5.disableReferrals (default value: false)
sun.security.krb5.maxReferrals (default value: 5)
- Limit the number of cross-realm referrals to avoid infinite loops. Default value is suggested by RFC 6806.
Note that sun.security.krb5.disableReferrals and sun.security.krb5.maxReferrals Security properties persist in the java.security configuration file and can be overwritten in run time by their corresponding System properties.