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

Stefan Metzmacher metze at samba.org
Fri Nov 22 05:24:44 EST 2019

Hi Nico,

>>> My idea was that Samba would use
>>> gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) to indicate
>>> the the transited list should not be checked.
>> I implemented GSS_KRB5_CRED_NO_TRANSIT_CHECK_X for
>> MIT, Heimdal (both upstream and Samba) and make use of
>> it in Samba.
> Hi,
> The right design for this is to use name attributes, not credential
> options.  Credential options should be banished altogether.
> To see why consider an acceptor application that wishes to examine the
> transit path (or whatever other attribute) an authenticated initiator
> principal took to reach the acceptor.  What credential should the
> acceptor inspect?  There is none to inspect, not for the initiator (not
> even if they delegated a credential, since that one might not have
> transited any realms).  The only way to inspect the transit path taken
> by the initiator is to inspect its name, as that's all we have for it.
> This is one reason we added name attributes.
> 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

Then I think we need iterate_acceptor_keytab also for MIT.
As far as I can see GSS_C_NO_NAME is the current trigger for
iterating the keytab. The functionality we need is, try every key
with a matching keytype, but ignore name and kvno.

> Credential options are not standardized, but name attributes are.
> Please use those.
> Consider this my code review for the Heimdal PR.
> I understand that this is probably a big change, and that this request
> may seem hostile (email being such a dry medium).  I'm willing to help
> you make this change, both for Heimdal and MIT -- I'll help with the
> code,

Thanks! I'm a bit lost on how to actually implement this, as
Heimdal doesn't seem to have a gsskrb5_gss_set_name_attribute() function
and krb5_gss_set_name_attribute() in MIT uses
krb5_authdata_set_attribute(), which just calls
krb5_authdata_context_module plugins. I'm not sure if authdata is what
we need here.

Are my changes to the lib/krb5 layer ok and we just need to change the
way the gsskrb5 layer triggers them? Or do we also need modifications there?

If you can tell me what attribute names we should use and how
the full call to gss_set_name_attribute() should look like,
I can start to change all the tests. But I need help to
implement the glue between gss_set_name_attribute() and
gsskrb5_acceptor_start() and kg_accept_krb5() respectively.

> and I'd be happy to have a conference call or exchange further
> emails.

I guess email is better for now, as we have everything archived.

Greg, do you agree, with changing to gss_set_name_attribute() instead of


-------------- 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/20191122/0c09a399/attachment-0001.bin

More information about the krbdev mailing list