On 2024-05-06 21:42, Wei-Jun Wang wrote:
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?
Looking at MIT Kerberos it has verify_pac_checksums() which is called
from krb5_kdc_verify_ticket() passing along the server's long term key
and the key of the krbtgt account. It very much seems that this happens
only on KDC side when the PAC gets passed along between MS KDC and MIT
KDC. I also don't see any urn: attributes for the long term key, as far
as I understand there is no straight forward way in MIT Kerberos to get
the long term key associated with an acceptor context.
Would you mind to file a JBS issue to expose this through
ExtendedGSSContext?
Michael
