Subject: Re: [kitten] Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation...

From: Stefan Metzmacher <[email-masked]>
Date: Thu, 5 Dec 2019 17:26:19 +0100

Hi Nico,

> On Fri, Nov 22, 2019 at 11:24:44AM +0100, Stefan Metzmacher wrote:
>>> Correspondingly and symmetrically, the right way to request some
>>> behavior on the side where the credential is available, is to associate
>>> that request with the desired_name for which the credential is acquired.
>>
>> So you mean we need to pass an explicit desired_name to
>> gss_acquire_cred_from() and use gss_set_name_attribute() calls
>> (for no_transit_check and iterate_acceptor_keytab) on that desired_name
>> before?
> 
> Oh, wait, right.  That's not going to work when you want a default
> credential.
> 
> Alright.  I've got a nasty cold and can't think straight, and deadlines
> to meet to boot too.  I'll respond more thoughtfully some time next
> week.

I hope you feel better again:-)

Looking at the gss_acquire_cred_from() prototype:

 GSSAPI_LIB_FUNCTION OM_uint32 GSSAPI_LIB_CALL
 gss_acquire_cred_from(OM_uint32 *minor_status,
                      gss_const_name_t desired_name,
                      OM_uint32 time_req,
                      const gss_OID_set desired_mechs,
                      gss_cred_usage_t cred_usage,
                      gss_const_key_value_set_t cred_store,
                      gss_cred_id_t *output_cred_handle,
                      gss_OID_set *actual_mechs,
                      OM_uint32 *time_rec)

I thought that additional cred_store elements would also
be a way to modify the resulting cred_handle.

On a similar matter I'll soon need a way to modify
a GSS_C_INITIATE cred_handle that forces KRB5_GC_CACHED to
be used, so that gss_init_sec_context() is garanteed to
avoid any network usage.

Any hints would be much appreciated:-)

Thanks!
metze