RFR: 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup

[Weijun Wang]

On Tue, 10 Aug 2021 13:45:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java line 59:
>> 
>>> 57:         private byte[] clientSvcTicketEnc; // S4U2Proxy only
>>> 58:         ReferralCacheKey (PrincipalName cname, PrincipalName sname,
>>> 59:                 PrincipalName user, Ticket clientSvcTicket) {
>> 
>> It's probably not necessary, but I somehow feel it will be clearer to add S4U2Type into the key. In fact, with all these info it almost looks like the key contains everything in a TGS-REQ (except for the timestamp maybe).
>
> Hmm.. in my view, adding the S4U2Type to the key will provide not much value other than minor consistency checks (in the form of debug-mode assertions) because the assumptions that a key with a non-null 'user' value is of S4U2Self type and that a key with a non-null 'clientSvcTicketEnc' value is of S4U2Proxy type (as suggested next to the field decl) are safe. The key type will not be necessary to make a key unique. One more comment to clarify just in case. The clientSvcTicketEnc value is somehow related to the other values in the key but it's not a 1 to 1 field mapping. This is because the TGS is the one that the user-to-be-impersonated sent to the middle service; whilst the cname and sname are related to a middle service ticket. If I'm correct, the cname in the key should match the client service ticket sname (both of them being the middle service name).

Not adding the type is OK, I said it's just to be a little clearer. I think you're right about the cname. It's always the one that actually sends the request.

What is "the TGS" (in "the TGS is the one")? `clientSvcTicketEnc`? BTW, is "client service ticket" a well known name? or we can name it "user"-something?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5036