RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806)
Weijun Wang
weijun.wang at oracle.com
Tue Apr 23 04:53:59 UTC 2019
Hi Martin,
Sorry for the delay. I went through the changes and they are all in the correct place. Next, I'll read the RFC carefully and make sure all behaviors are correct. In the mean time, you can start preparing the CSR.
BTW, what kinds of real world KDC have you tested against?
Thanks,
Max
>
>> On Dec 10, 2018, at 11:39 PM, Martin Balao <mbalao at redhat.com> wrote:
>>
>> 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.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,
>> 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
>
More information about the security-dev
mailing list