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

[Martin Balao]

On Tue, 10 Aug 2021 14:08:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 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?

The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that all these names are a bit confusing -but so it is the underlying protocol-. I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the hopes of suggesting some similarity between S4U2Proxy and S4U2Self and make it more clear-. Agree?

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

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