> On May 6, 2024, at 2:55 PM, Osipov, Michael (IN IT IN)
> <michael.osi...@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.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
>
