On Tue, 10 Aug 2021 14:08:24 GMT, Weijun Wang <wei...@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
