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.
BTW, when you said "disjoint to the security context", the long term key of the
server *is* not related to any context.
Thanks,
Weijun
> On May 6, 2024, at 1:03 PM, Osipov, Michael (IN IT IN)
> <michael.osi...@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
