True, and in fact that is what I am going to do for now: same principal,
same etype, trying to get the KeyTab object from the Subject's private
creds, but still it loads more keys than necessary and and will incur
unnecessary signature calculations.
Thank your for your consideration.
On 2024-05-07 20:07, Wei-Jun Wang wrote:
I'll think about the security impact. On one hand you can already call KeyTab
API to get all the keys...
On May 7, 2024, at 3:44 AM, Osipov, Michael (IN IT IN)
<michael.osi...@innomotics.com> wrote:
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
