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

--===============6756436259995256026==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="uB1NnpKCNTTJnpqZJe9TAfToAyI3ReWK4"

--uB1NnpKCNTTJnpqZJe9TAfToAyI3ReWK4
Content-Type: multipart/mixed; boundary="1nQgGYMk7ondMoMQPMm10l3Re2p7B4t8j";
	protected-headers="v1"
From: Stefan Metzmacher <[email protected]>
To: Nico Williams <[email protected]>
Cc: [email protected], Viktor Dukhovni <[email protected]>,
	Samba Technical <[email protected]>,
	"[email protected] Dev List" <[email protected]>,
	"[email protected]" <[email protected]>,
	Greg Hudson <[email protected]>
Message-ID: <[email protected]>
Subject: Re: [kitten] Checking the transited list of a kerberos ticket in a
	transitive cross-realm trust situation...
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<20191121223908.GC26241@localhost>
In-Reply-To: <20191121223908.GC26241@localhost>

--1nQgGYMk7ondMoMQPMm10l3Re2p7B4t8j
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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.
>=20
> Hi,
>=20
> The right design for this is to use name attributes, not credential
> options.  Credential options should be banished altogether.
>=20
> 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.
>=20
> 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=
=2E

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?

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.
>=20
> Consider this my code review for the Heimdal PR.
>=20
> 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 the=
re?

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
gss_set_cred_option().

Thanks!
metze


--1nQgGYMk7ondMoMQPMm10l3Re2p7B4t8j--

--uB1NnpKCNTTJnpqZJe9TAfToAyI3ReWK4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfFbGo3YXpfgryIw9DbX1YShpvVYFAl3Xt2wACgkQDbX1YShp
vVaVwxAAvsm5rrmLLK0kBQELyJOc6yKMLvJldOAvEDxvYeshr6VM/R3fBHww+n63
D7/cTsyrd0cm1gDgAZS9XR7rBB99k46rzl97oIGWYk735xhBmDMBSevTILS7TuYv
BFerPkqIutK3HYB9AJqT6/z3YP0i5RsAz1XrgrSOS8XJobdw99KyO0rdjmZHmZdk
kmbVeh82kx0nWEsub196gYdHRwePbuLSZw8eo+ZKFUD7XOInjoRiPGD5plBTq1Fk
S5pHvBjVzUW1mVXqFe0hHkGbFqaxu9oSQEIXE7F3NnQZCoh0bjuU8pCm8qcX8mfF
drIL1jr+mYlQo99PkO7rCE7U4Le3Z1QspmXDxf7mX0SFHe9uPCf9Eux0EeUCPSK0
75Tn6RvDwteJmwlBLTWFwvTd63H9s7tPCAgnURXPDy0c9S1kG/jDFHHsg/YJsI+z
FjlXueyt/YWASOKTVu6LH5/bMZwiVuuYJUsZ9lWdZ3yOq84t1VSRintUc/CuGyM4
ZMNb5DEL+3aVNIluShAtBOOBkbTWTORVGi2sQ2YshATk6vMzfO41y5HsSZ2Ra42d
HdNSh213PRqt6J9lFMjXQC5JrqQr1N0fvfijKzU9fqFLyZCb99Z13LW2KGmRuMar
yPmNA+3c26kKxrnMtNAe2nDY8PSRuFrqvfSJxTSkfDQk+TA+IAI=
=tz6A
-----END PGP SIGNATURE-----

--uB1NnpKCNTTJnpqZJe9TAfToAyI3ReWK4--

--===============6756436259995256026==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev

--===============6756436259995256026==--