Hi, 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]. Webrev.00: * 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 * FAST * 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 ticket) * 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....@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, Martin.- -- [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] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1421 [6] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1665 [7] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_as_req.c#L326 [8] - https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_tgs_req.c#L724
