Constrained Delegation with certificate and GSS API

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Constrained Delegation with certificate and GSS API

Puran Chand
Hi,

I see 'gss_acquire_cred_impersonate_name' should be used to obtain
impersonation token on behalf of user and the API expects
User-Principal-Name 'gss_name_t' as input to identify the user.

I was wondering if there is similar API to perform same with
user-certificate this time instead of UPN.
I hope it should send a AS-REQ with  PA-DATA P4-S4U-X509-USER with
certificate (with my limited knowledge).

If there isn't any API, I would be happy to work upon this.

Let me know where to start.
Thanks

-Puran
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Constrained Delegation with certificate and GSS API

Greg Hudson
On 5/6/20 12:25 AM, Puran Chand wrote:> I was wondering if there is
similar API to perform same with
> user-certificate this time instead of UPN.
> I hope it should send a AS-REQ with  PA-DATA P4-S4U-X509-USER with
> certificate (with my limited knowledge).

There isn't yet.  Release 1.18 included a lot of work on the internals,
as well as a kvno option (-F), but we haven't added any API for this
operation yet.  There is a work-in-progress pull request from Isaac
Boukris here:

https://github.com/krb5/krb5/pull/1063

There may be alternative designs for the API; for instance, we could
perhaps instead define a new name type and use
gss_acquire_cred_impersonate_name().
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Constrained Delegation with certificate and GSS API

Isaac Boukris
On Wed, May 6, 2020 at 6:46 AM Greg Hudson <[hidden email]> wrote:
>
> https://github.com/krb5/krb5/pull/1063
>
> There may be alternative designs for the API; for instance, we could
> perhaps instead define a new name type and use
> gss_acquire_cred_impersonate_name().

Yes, that would solve the authdata problem and we can skip the name+cert case.

@Puran, feel free to develop it on top PR 1063 if you like, it already
got some tests.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Constrained Delegation with certificate and GSS API

Puran Chand
I don't see a name type for certificate as per
https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html#name-types

Also as I understand, I need to get rid of
gss_acquire_cred_impersonate_cert and instead invoke relevant code from
gss_acquire_impersonate_name based on name type.
LMK your thoughts.

-Puran

On Wed, May 6, 2020 at 1:26 PM Isaac Boukris <[hidden email]> wrote:

> On Wed, May 6, 2020 at 6:46 AM Greg Hudson <[hidden email]> wrote:
> >
> > https://github.com/krb5/krb5/pull/1063
> >
> > There may be alternative designs for the API; for instance, we could
> > perhaps instead define a new name type and use
> > gss_acquire_cred_impersonate_name().
>
> Yes, that would solve the authdata problem and we can skip the name+cert
> case.
>
> @Puran, feel free to develop it on top PR 1063 if you like, it already
> got some tests.
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Constrained Delegation with certificate and GSS API

Isaac Boukris
On Mon, May 11, 2020 at 6:55 AM Puran Chand <[hidden email]> wrote:
>
> I don't see a name type for certificate as per https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html#name-types

The idea was to add a new name type.

> Also as I understand, I need to get rid of gss_acquire_cred_impersonate_cert and instead invoke relevant code from gss_acquire_impersonate_name based on name type.
> LMK your thoughts.

Yeah, the caller would import the cert data with the new name-type and
pass it to gss_acquire_cred_impersonate_name() as desired_name.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Constrained Delegation with certificate and GSS API

Puran Chand
I see gss_import_name() put the name_type to gss_union_name_t->name_type
and cert_data in gss_union_name_t->external_name.
However I don't understand how this should pass down from GSS API
(gss_add_cred_impersonate_name) to krb5
API(krb5_gss_acquire_cred_impersonate_name).
I see gss_name_t passed down to krb5 API isn't what received in GSS API.
Its gss_union_name_t->mech_name and the same is converted
into krb5_gss_name_t eventually.
And I believe  krb5_gss_name_t  is constructed into
krb5_gss_import_name/imp_name.c, IDK what would be the right place to store
cert_data in krb5_gss_name_t, should the name_type be copied to
krb5_gss_name_t->krb5_principal->type and cert data to
krb5_gss_name_t->krb5_principal->realm?

-Puran

On Tue, May 12, 2020 at 3:07 AM Isaac Boukris <[hidden email]> wrote:

> On Mon, May 11, 2020 at 6:55 AM Puran Chand <[hidden email]> wrote:
> >
> > I don't see a name type for certificate as per
> https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html#name-types
>
> The idea was to add a new name type.
>
> > Also as I understand, I need to get rid of
> gss_acquire_cred_impersonate_cert and instead invoke relevant code from
> gss_acquire_impersonate_name based on name type.
> > LMK your thoughts.
>
> Yeah, the caller would import the cert data with the new name-type and
> pass it to gss_acquire_cred_impersonate_name() as desired_name.
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Constrained Delegation with certificate and GSS API

Isaac Boukris
On Sun, Jun 7, 2020 at 4:57 PM Puran Chand <[hidden email]> wrote:
>
> I see gss_import_name() put the name_type to gss_union_name_t->name_type and cert_data in gss_union_name_t->external_name.
> However I don't understand how this should pass down from GSS API (gss_add_cred_impersonate_name) to krb5 API(krb5_gss_acquire_cred_impersonate_name).
> I see gss_name_t passed down to krb5 API isn't what received in GSS API. Its gss_union_name_t->mech_name and the same is converted into krb5_gss_name_t eventually.
> And I believe  krb5_gss_name_t  is constructed into krb5_gss_import_name/imp_name.c, IDK what would be the right place to store cert_data in krb5_gss_name_t, should the name_type be copied to  krb5_gss_name_t->krb5_principal->type and cert data to krb5_gss_name_t->krb5_principal->realm?

You're looking at the right places, for a simple start you could add a
krb5_data member 'cert' to krb5_gss_name_t struct, copy the
certificate data in there at krb5_gss_import_name() and set princ to
NULL, then alter in kg_impersonate_name() you check if cert->length !=
0 and use the cert instead of princ.

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