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