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

[Osipov, Michael (IN IT IN)]

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.osipov at 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.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
> 
>