Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

[Wei-Jun Wang]

> On May 6, 2024, at 2:55 PM, Osipov, Michael (IN IT IN) <michael.osipov at innomotics.com> wrote:
> 
> Hi Weijun,
> 
> On 2024-05-06 20:51, Wei-Jun Wang wrote:
>> Hi Michael,
>> I see you've just reported a bug on KeyTab. Is that your latest workaround to the request here? That's also the only one I can think of now.
> 
> The bug is unrelated. I just noticed it when working on the issue.
> 
>> BTW, when you said "disjoint to the security context", the long term key of the server *is* not related to any context.
> 
> I know, but when the service ticket is analyzed the acceptor context does try to find a long term key for requested principal, KVNO, and etype, no? Then you can identify the long term key which has been used to established the context? Is my understanding wrong?

Yes, you're right.

Do you know how other krb5 libraries do this?

Thanks,
Weijun


> 
> Michael
> 
>>> On May 6, 2024, at 1:03 PM, Osipov, Michael (IN IT IN) <michael.osipov at innomotics.com> wrote:
>>> 
>>> On 2024-05-06 16:32, Osipov, Michael (IN IT IN) wrote:
>>>> Folks,
>>>> I have a GSS security context established and need to calculate a signature on data received form the client. The client submits me a forwarded signature calculated by the KDC (Active Directory) with the server's long term key from the keytab.
>>>> As far as I can see ExtendedGSSContext only exposes the server's session key, but not the long term key used to accept this security context.
>>>> The only way I have found working is either:
>>>>> PrincipalName name = new PrincipalName("...", PrincipalName.KRB_NT_PRINCIPAL);
>>>>> EncryptionKey[] encKeys = EncryptionKey.acquireSecretKeys(name, "...");
>>>>> EncryptionKey encKey = EncryptionKey.findKey(serverSignature.getType().getEType(), encKeys);
>>>> which is ugly because these are really really private classes and the key is disjoint with the context hoping that the KVNO matched with the key I have here or I need to pull in a lot of dependencies from Apache Kerby to get the key.
>>>> The signature calculation succeeds with additional private classes, but that is another story.
>>>> Any tip would be helpful. In case you ask, I want to calculate: https:// learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/ a194aa34-81bd-46a0-a931-2e05b87d1098
>>>> Ideal solution would be of course:
>>>> Key longTermKey = (Key) extGssContext.inquireSecContext(InquireType.KRB5_GET_LONG_TERM_KEY);
>>>> I am on Java 8+
>>> 
>>> While this is not the ideal situation this works:
>>>> KeyTab keytab = KeyTab.getUnboundInstance(new File("..."));
>>>> KerberosPrincipal principal = new KerberosPrincipal("...", KerberosPrincipal.KRB_NT_PRINCIPAL);
>>>> KerberosKey[] keys = keytab.getKeys(principal);
>>> 
>>> The key still remains disjoint to the security context in terms of etype and kvno. I also noticed a possible bug in principal name comparison I need to check and will report separately.
>>> 
>>> Additional pointers still appreciated.
>>> 
>>> M
>