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

Stefan Metzmacher metze at samba.org
Thu Jan 23 06:25:50 EST 2020

Hi Nico,

it would be great if we could make some progress here...

Any hints how to avoid gss_set_cred_option() with a more modern
construct that would be acceptable for upstream MIT and Heimdal.


Am 05.12.19 um 17:26 schrieb Stefan Metzmacher:
> 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:
>  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
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20200123/a3385c1c/attachment-0001.bin

More information about the krbdev mailing list