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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============6301525725298379424==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="oLy5S5ZQeCm5mof6uhBwqCMowoKCy9ARG"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--oLy5S5ZQeCm5mof6uhBwqCMowoKCy9ARG
Content-Type: multipart/mixed; boundary="lGvB60PQRu0oRg0PbUagwaDFPVsJ1XqEo";
 protected-headers="v1"
From: Stefan Metzmacher <[email protected]>
To: Nico Williams <[email protected]>
Cc: "[email protected]" <[email protected]>,
 Viktor Dukhovni <[email protected]>,
 Samba Technical <[email protected]>,
 "[email protected] Dev List" <[email protected]>, [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]>
 <20191121223908.GC26241@localhost>
 <[email protected]>
 <20191122224526.GA28614@localhost>
 <[email protected]>
In-Reply-To: <[email protected]>

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

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.

Thanks!
metze

Am 05.12.19 um 17:26 schrieb Stefan Metzmacher:
> Hi Nico,
>=20
>> 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 associ=
ate
>>>> that request with the desired_name for which the credential is acqui=
red.
>>>
>>> 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_na=
me
>>> 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 deadline=
s
>> to meet to boot too.  I'll respond more thoughtfully some time next
>> week.
>=20
> I hope you feel better again:-)
>=20
> Looking at the gss_acquire_cred_from() prototype:
>=20
>  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)
>=20
> I thought that additional cred_store elements would also
> be a way to modify the resulting cred_handle.
>=20
> 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.
>=20
> Any hints would be much appreciated:-)
>=20
> Thanks!
> metze
>=20
> _______________________________________________
> krbdev mailing list             [email protected]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>=20



--lGvB60PQRu0oRg0PbUagwaDFPVsJ1XqEo--

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

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

iQIzBAEBCgAdFiEEfFbGo3YXpfgryIw9DbX1YShpvVYFAl4pgr4ACgkQDbX1YShp
vVatxA/+Kds5dYQv0utMrBIfjB4RlMhUEk60QGispC/T5pKavK9dUFV75f7wzH9M
gSNgr2klV9wlP40zw8DaIB0DBtkXcEXSJW9hF7yTVg64TfoNjg1vYugJzUwk3Lf2
1P2Hj0fX17brk40ZwdNNRGDdVoIgosHeETj8DRkC5L9QIiRlf5vlU5MetVeUuYle
QpXhzC2jfSGMewWWMXFhNvwzcibV4fZ1xr2JZOCNcHjTwqSCQixhzpeMJQNQJVE4
zV+UVbjvaGBHRHKYI1qdVuj8qq1OLxqW1Zfq7OxD5y5Sy8ozCAjgM8VGnuj/l8wt
LBWzBDVUiYuYWpigiLUfQ/lMyoCbKJlEZ1NGL5IjbBqGcvn/0WPC2+8241nPr6pX
j+BuPMyhQgagfW/XbSY5sNUDCUc2zmaZUFi9/cnRq91rorGrTiITIRi8Xpx/RIUb
S1v17pFw4As7IroEyH1CgI4ZLSckoJGzdexTvYBtlTafhDJWf5U4851kCAgzcQZa
TtS+tR61HaEO7XFMaHAG7oJRtUYcrKxvN/PFvceAkYblQIYAT7NSZ31OSto3PpAa
qpfbt+XbABQoKjAiq9Nk8RxsadNLfUp8gAG22yNFYJs9Mc7GkYogx5dVEbtdGWLg
fVsTjdno1Nmj8Hyp4UlIVDbYPzDKnZH2XgGDbOrOxTV/rj6YNYk=
=M3mM
-----END PGP SIGNATURE-----

--oLy5S5ZQeCm5mof6uhBwqCMowoKCy9ARG--


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

_______________________________________________
Kitten mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/kitten

--===============6301525725298379424==--