RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806)

Martin Balao mbalao at redhat.com
Mon Dec 10 15:39:55 UTC 2018


I'd like to propose an implementation of Kerberos cross-realm referrals
for OpenJDK's client, according to RFC 6806 [1].

Request for Enhancement: "JDK-8215032 - Support Kerberos cross-realm
referrals (RFC 6806)" [2].

Related tickets: "JDK-6631053 - Support canonicalize in Kerberos
configuration file" [3] and "JDK-8005819 - Support cross-realm MSSFU" [4].


 * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00.zip

Implementation notes:

 * System properties introduced:
  * sun.security.krb5.disableReferrals: disable this feature
  * sun.security.krb5.maxReferrals: max referral hops for both client
and server referrals (5 by default, as suggested by RFC 6806)
  * CSR will be needed

 * NT-ENTERPRISE principals
  * Supported
  * Krb5LoginModule has not been extended to use it. However, I'm open
to discuss this API first and propose an implementation then -either in
the context of this enhancement or in a new one-.

 * Client referrals
  * Supported
  * Client announces support setting CANONICALIZE flag
   * Fallback: if a failure occurs, client retries without CANONICALIZE flag

 * Server referrals
  * Supported
  * Client announces support setting CANONICALIZE flag
   * Fallback: if a failure occurs, client retries without CANONICALIZE flag

  * RFC 6806 - Section 11 FAST scheme supported
   * Complete FAST support (RFC 6113) is out of scope
  * RFC 6806 - Section 11 FAST is mandatory for AS-REQ, and optional for
TGS-REQ. Client does not ask for it in TGS requests -sending
PA-REQ-ENC-PA-REP PA data- for compatibility reasons. Some servers do
not support PA-REQ-ENC-PA-REP in TGS requests and if no checksum is
available in TGS responses (even though ENC_PA_REP flag is set), no
enforcement is possible.
   * MIT's client does not send PA-REQ-ENC-PA-REP requests for TGS, only
for TGTs [5]
   * MIT's client only verifies PA-REQ-ENC-PA-REP for TGTs [6]
   * MIT's KDC supports PA-REQ-ENC-PA-REP in TGT [7] and TGS [8]
replies, but Microsoft's Active Directory 2016 does not apparently.

 * Cache
  * If a referral loop is introduced when adding a new entry to the
cache, we break the loop by invalidating the "next" entry
  * Adding an entry to the cache may override a previous one
   * The assumption is that newer information is more accurate
   * For a given Principal Name, there can only be one "Realm -> Next
Realm" referral entry (whose lifetime is given by the referral krbtgt

 * Security
  * Client name changes are allowed in AS-REPs only if:
   * Client sent CANONICALIZE
   * Server supports RFC 6806 - Section 11 FAST
   * Authenticated checksum is correct
  * Server name changes are allowed in TGS-REPs only if:
   * Client sent CANONICALIZE
   * It's for a referral (sname = krbtgt/TO-REALM.COM at FROM-REALM.COM)

 * Testing
  * KDC used for testing purposes was extended to include basic support
of RFC 6806 server-side
   * NT-ENTERPRISE principals
   * Client referrals
   * Server referrlas
   * FAST - Section 11 scheme
  * ReferralsTest functional test added
   * Client referral with NT-ENTERPRISE principal
   * Server referral

Regressing testing:

 * No regressions found in jdk/sun/security/krb5 category.
  * Test results: passed: 128

I'd be grateful if someone can have a look.

Kind regards,

[1] - https://tools.ietf.org/html/rfc6806.html
[2] - https://bugs.openjdk.java.net/browse/JDK-8215032
[3] - https://bugs.openjdk.java.net/browse/JDK-6631053
[4] - https://bugs.openjdk.java.net/browse/JDK-8005819
[5] -
[6] -
[7] -
[8] -

More information about the security-dev mailing list