Canonical/portable way to obtain long term key for a GSS security context (acceptor side)

[Osipov, Michael (IN IT IN)]

On 2024-05-06 21:42, Wei-Jun Wang wrote:
> 
> 
>> On May 6, 2024, at 2:55 PM, Osipov, Michael (IN IT IN) <michael.osipov at 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