Alternative proxy-creds API for constrained-delegation

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

Alternative proxy-creds API for constrained-delegation

Isaac Boukris
Hi,

Currently we have an API in MIT to acquire delegated proxy-creds via
gss_accept(), if the credentials include initiator creds (GSS_C_BOTH).

I find this API is really nice as a drop in replacement for
tgt-forwarding, and can be relatively easily adopted by applications,
but on the other hand maybe not suitable for all usage as it:
a. exposes the TGT of the impersonator in the proxy-creds.
b. it may trigger TGT acquisition (with default client kt) in the
gss_accept() call.

I wonder if we can have an alternative API, like
gss_set_{cred/context}_option, to tell gss_accept() to simply delegate
the service ticket in the delegated credentials without any tgt (i
think we used to produce such creds when no forwardable flag was
found). This by itself would provide a simple way to re-authenticate
the client locally.

Then we can implement client plugins, that are invoked in case the
cache hasn't got the requested service ticket, and doesn't have any
TGT.  When invoked, they'ed authenticate to a local host daemon, such
as winbind or gss-proxy or anyone with access to the long term keys,
using the ticket from the tgt-less cache, and get back credentials
(service ticket) for a next service via S4U2Proxy (encrypted using the
established gss context).

If we use cred options, we could use the same flag for
gss_impersonate() as well, otherwise one could call gss_accept() on
the creds acquired via gss_impersonate().

Thoughts?

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

Re: Alternative proxy-creds API for constrained-delegation

Greg Hudson
Summary of IRC and voice conversations on this topic:

The problem we are trying to solve is making a login server (e.g. a host
running sshd) use constrained delegation instead of traditional TGT
delegation.  This is harder than, say, the web server scenario, because
a login session should not have access to a host TGT.

The first half of the problem is a way for acceptor applications to save
and store just the service ticket (without the host TGT)--most likely
through delegated_cred_handle.  We considered several options:

* Simply do this all the time--so sshd would start storing a ccache with
just the evidence ticket whenever Kerberos authentication is performed
and no TGT is delegated.  Unless the host is configured for constrained
delegation, this ccache would not be very useful because it does not
contain a TGT.  In general applications would not behave much
differently in the presence of this cache (they would tend to fail in
gss_init_sec_context() just as they would if there were no creds), but I
objected because it is likely to create rough edges for users and scripts.

* Make the application signal for the service ticket using a cred option
or name attribute.  Nico argued that in most cases, this just would
devolve to server application configuration, which is no different from
krb5 mech configuration, so this would just be busy-work for the
acceptor code.

* Configure this via krb5.conf or an environment variable or both.
Isaac suggested an ordered list of delegated credential types, which
would allow flexible acceptor policy configuration such as "always
return just the service ticket, even if the client delegates a TGT
and/or the acceptor cred is GSS_C_BOTH."

There is general agreement on a krb5.conf option, with unclear agreement
on whether there should also be an environment variable or application
signal or all three.

The second half of the problem is a facility for using a "just the
service ticket" credential to do S4U2Proxy.  Since S4U2Proxy requires a
host TGT, this has to be done via a privileged service running on the
host.  I think there is general agreement that this should be done via
the existing gss-proxy facility unless we run into a roadblock.

There was some discussion of whether gss-proxy needs access to
additional specialized APIs to combine the user's credentials with the
host's credentials.  Nico noted that this could likely be accomplished
via mech configuration rather than an API, and Simo noted that gss-proxy
could re-authenticate with the service ticket and GSS_C_BOTH credentials
to create a proxy cred.  So I think there are existing options for the
implementation, but we can revisit this as needed.


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

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <[hidden email]> wrote:

>
> Summary of IRC and voice conversations on this topic:
>
> The problem we are trying to solve is making a login server (e.g. a host
> running sshd) use constrained delegation instead of traditional TGT
> delegation.  This is harder than, say, the web server scenario, because
> a login session should not have access to a host TGT.
>
> The first half of the problem is a way for acceptor applications to save
> and store just the service ticket (without the host TGT)--most likely
> through delegated_cred_handle.  We considered several options:
>
> * Simply do this all the time--so sshd would start storing a ccache with
> just the evidence ticket whenever Kerberos authentication is performed
> and no TGT is delegated.  Unless the host is configured for constrained
> delegation, this ccache would not be very useful because it does not
> contain a TGT.  In general applications would not behave much
> differently in the presence of this cache (they would tend to fail in
> gss_init_sec_context() just as they would if there were no creds), but I
> objected because it is likely to create rough edges for users and scripts.
>
> * Make the application signal for the service ticket using a cred option
> or name attribute.  Nico argued that in most cases, this just would
> devolve to server application configuration, which is no different from
> krb5 mech configuration, so this would just be busy-work for the
> acceptor code.

I'd still love to see an application signal for the service ticket
using a cred option or name attribute, more likely to help in samba.

> * Configure this via krb5.conf or an environment variable or both.
> Isaac suggested an ordered list of delegated credential types, which
> would allow flexible acceptor policy configuration such as "always
> return just the service ticket, even if the client delegates a TGT
> and/or the acceptor cred is GSS_C_BOTH."
>
> There is general agreement on a krb5.conf option, with unclear agreement
> on whether there should also be an environment variable or application
> signal or all three.
>
> The second half of the problem is a facility for using a "just the
> service ticket" credential to do S4U2Proxy.  Since S4U2Proxy requires a
> host TGT, this has to be done via a privileged service running on the
> host.  I think there is general agreement that this should be done via
> the existing gss-proxy facility unless we run into a roadblock.
>
> There was some discussion of whether gss-proxy needs access to
> additional specialized APIs to combine the user's credentials with the
> host's credentials.  Nico noted that this could likely be accomplished
> via mech configuration rather than an API, and Simo noted that gss-proxy
> could re-authenticate with the service ticket and GSS_C_BOTH credentials
> to create a proxy cred.  So I think there are existing options for the
> implementation, but we can revisit this as needed.

What does the daemon do once it get a proxy-creds upon accepting with
GSS_C_BOTH? Do we have an API to do init_sec(), just get the ticket,
extract it and return it to the caller, maybe krb5 api? How does the
caller gets it injected to its cache, would that be possible?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Greg Hudson
On Tue, Jun 02, 2020 at 02:11:42PM -0400, Greg Hudson wrote:
> Summary of IRC and voice conversations on this topic:

Thanks.  I want to restate a few principles here that I mentioned on the
call:

 - where possible, existing APIs should just work if the semantics fit

   (Here dealing with an S4U2Proxy credential as a deleg_cred_handle
   will work.  The detailed differences between such a cred and a
   traditional delegated cred are the kind that GSS abstracts away just
   fine via the cred handle type.)

 - we don't need new APIs for configuration unless that configuration
   needs to be dynamic, or specifiable by the application and
   specifically not in krb5.conf or the like

    - but we can _also_ add new APIs for configuration

    - we have three existing ways in GSS today to do slot in application
      configuration:

       - name attributes
       - cred options
       - cred store key/value set (for gss_add/acquire_cred_from(),
         gss_store_cred_into())

      which the last is the nicest for configuration because all the
      values are strings -- look ma', no OIDs!

 - env vars should by and large have configuration equivalents, and
   should rarely be the only mechanism for specifying behavior, but
   there can be exceptions

> The problem we are trying to solve is making a login server (e.g. a host
> running sshd) use constrained delegation instead of traditional TGT
> delegation.  This is harder than, say, the web server scenario, because
> a login session should not have access to a host TGT.

Right.  An S4U2Proxy cred output by gss_accept_sec_context() can be used
in the same process without further ado, but storing it is more
complicated because we have a privilege separation issue that will force
us to have an IPC service.

> The first half of the problem is a way for acceptor applications to save
> and store just the service ticket (without the host TGT)--most likely
> through delegated_cred_handle.  We considered several options:

I wouldn't do it any other way than as a deleg_cred_handle.

> * Simply do this all the time--so sshd would start storing a ccache with
> just the evidence ticket whenever Kerberos authentication is performed
> and no TGT is delegated.  Unless the host is configured for constrained
> delegation, this ccache would not be very useful because it does not
> contain a TGT.  In general applications would not behave much
> differently in the presence of this cache (they would tend to fail in
> gss_init_sec_context() just as they would if there were no creds), but I
> objected because it is likely to create rough edges for users and scripts.

I agree this need not be a default behavior, though I believe it could
be.

> * Make the application signal for the service ticket using a cred option
> or name attribute.  Nico argued that in most cases, this just would
> devolve to server application configuration, which is no different from
> krb5 mech configuration, so this would just be busy-work for the
> acceptor code.

+1

> * Configure this via krb5.conf or an environment variable or both.
> Isaac suggested an ordered list of delegated credential types, which
> would allow flexible acceptor policy configuration such as "always
> return just the service ticket, even if the client delegates a TGT
> and/or the acceptor cred is GSS_C_BOTH."

+1.  I agree with Isaac's proposal.

> There is general agreement on a krb5.conf option, with unclear agreement
> on whether there should also be an environment variable or application
> signal or all three.

I object to none, but a krb5.conf option is necessary, while the others
are nice-to-haves.

> The second half of the problem is a facility for using a "just the
> service ticket" credential to do S4U2Proxy.  Since S4U2Proxy requires a
> host TGT, this has to be done via a privileged service running on the
> host.  I think there is general agreement that this should be done via
> the existing gss-proxy facility unless we run into a roadblock.
>
> There was some discussion of whether gss-proxy needs access to
> additional specialized APIs to combine the user's credentials with the
> host's credentials.  Nico noted that this could likely be accomplished
> via mech configuration rather than an API, and Simo noted that gss-proxy
> could re-authenticate with the service ticket and GSS_C_BOTH credentials
> to create a proxy cred.  So I think there are existing options for the
> implementation, but we can revisit this as needed.

It's certainly easier to make changes to gss-proxy than to other GSS
apps (one vs. many), but I believe everything needed here is
configuration.

The question that comes up is "how to find the keytab that has the keys
for a given service principal?", and, if you want to cache TGTs obtained
with those, "how to find that cache?".  The answer to these is more
configuration -- new krb5 APIs may be needed, though they could be
private.

I believe we ended with roughly agreeing on all these various points
(though maybe not on the principles I laid out above).

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

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Isaac Boukris
On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> What does the daemon do once it get a proxy-creds upon accepting with
> GSS_C_BOTH? Do we have an API to do init_sec(), just get the ticket,
> extract it and return it to the caller, maybe krb5 api? How does the
> caller gets it injected to its cache, would that be possible?

If you get a deleg_cred_handle, you should be able to use it in the same
process without further ado -- no changes needed to code calling
gss_init_sec_context(), and no gss-proxy should be needed either.

I don't think we even need GSS_C_BOTH to have been used to acquire the
acceptor credential.  What is needed is that the acceptor process have
access to the service's credentials, which clearly it must have in order
to accept.

My preference is to not make GSS_C_BOTH use a requirement on the
acceptor side.

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

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Isaac Boukris
On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> I'd still love to see an application signal for the service ticket
> using a cred option or name attribute, more likely to help in samba.

What exactly would the option specify?  I'm certain we can fit it in one
of three different ways though.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Nico Williams
On Wed, Jun 3, 2020 at 12:03 AM Nico Williams <[hidden email]> wrote:

>
> On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > What does the daemon do once it get a proxy-creds upon accepting with
> > GSS_C_BOTH? Do we have an API to do init_sec(), just get the ticket,
> > extract it and return it to the caller, maybe krb5 api? How does the
> > caller gets it injected to its cache, would that be possible?
>
> If you get a deleg_cred_handle, you should be able to use it in the same
> process without further ado -- no changes needed to code calling
> gss_init_sec_context(), and no gss-proxy should be needed either.

I agree no changes needed to code calling gss_init_sec_context()
should be made, but if we only have a tgt-less cache someone would
have to do the work, thus a proxy is needed. I was trying to imagine
how the proxy code would look like, and how would it return the
requested ticket to be saved in the client cache for next usages.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Nico Williams
On Wed, Jun 3, 2020 at 12:05 AM Nico Williams <[hidden email]> wrote:
>
> On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > I'd still love to see an application signal for the service ticket
> > using a cred option or name attribute, more likely to help in samba.
>
> What exactly would the option specify?  I'm certain we can fit it in one
> of three different ways though.

It could specify the delegation-policy for this creds/context for
example, or we can make the ticket always available via
name-attributes like Simo suggested, but that would be somewhat
unrelated work.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Isaac Boukris
On Wed, Jun 03, 2020 at 01:16:15AM +0200, Isaac Boukris wrote:

> On Wed, Jun 3, 2020 at 12:03 AM Nico Williams <[hidden email]> wrote:
> > On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > > What does the daemon do once it get a proxy-creds upon accepting with
> > > GSS_C_BOTH? Do we have an API to do init_sec(), just get the ticket,
> > > extract it and return it to the caller, maybe krb5 api? How does the
> > > caller gets it injected to its cache, would that be possible?
> >
> > If you get a deleg_cred_handle, you should be able to use it in the same
> > process without further ado -- no changes needed to code calling
> > gss_init_sec_context(), and no gss-proxy should be needed either.
>
> I agree no changes needed to code calling gss_init_sec_context()
> should be made, but if we only have a tgt-less cache someone would
> have to do the work, thus a proxy is needed. I was trying to imagine
> how the proxy code would look like, and how would it return the
> requested ticket to be saved in the client cache for next usages.

That still involves no API changes.  The proxy _could_ share a cache
with the user process calling it if that's a useful optimization, but
it's an optimization, and probably not essential.  For the optimized
case, the proxy client would have to be invoked by the non-proxy krb5
mech if it doesn't find the desired service ticket in the cache.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Isaac Boukris
On Wed, Jun 03, 2020 at 01:29:23AM +0200, Isaac Boukris wrote:

> On Wed, Jun 3, 2020 at 12:05 AM Nico Williams <[hidden email]> wrote:
> > On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > > I'd still love to see an application signal for the service ticket
> > > using a cred option or name attribute, more likely to help in samba.
> >
> > What exactly would the option specify?  I'm certain we can fit it in one
> > of three different ways though.
>
> It could specify the delegation-policy for this creds/context for
> example, or we can make the ticket always available via
> name-attributes like Simo suggested, but that would be somewhat
> unrelated work.

So you're saying you want to be able to say "only accept traditional
delegated credentials, don't do S4U2Proxy" and also be able to say
"either is fine"?  And configuration is not enough?  Anyways, my
preference for that is to use gss_acquire_cred_from().
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Isaac Boukris
On Tue, Jun 02, 2020 at 10:30:47PM -0500, Nico Williams wrote:

> On Wed, Jun 03, 2020 at 01:29:23AM +0200, Isaac Boukris wrote:
> > On Wed, Jun 3, 2020 at 12:05 AM Nico Williams <[hidden email]> wrote:
> > > On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > > > I'd still love to see an application signal for the service ticket
> > > > using a cred option or name attribute, more likely to help in samba.
> > >
> > > What exactly would the option specify?  I'm certain we can fit it in one
> > > of three different ways though.
> >
> > It could specify the delegation-policy for this creds/context for
> > example, or we can make the ticket always available via
> > name-attributes like Simo suggested, but that would be somewhat
> > unrelated work.
>
> So you're saying you want to be able to say "only accept traditional
> delegated credentials, don't do S4U2Proxy" and also be able to say
> "either is fine"?  And configuration is not enough?  Anyways, my
> preference for that is to use gss_acquire_cred_from().

I'll take that back!  The right interface for this is
gss_store_cred_into() or gss_store_cred_into2().

Here's the idea:

 - you always get a deleg_cred_handle if one was delegated or S4U2Proxy
   is available,

 - you tell gss_store_cred_into() about what you're willing to store and
   with what options,

 - if you say "only real creds" then gss_store_cred_into() will not
   store S4U2Proxy creds.

In Heimdal's master branch we have all of these gss_store_cred_into()
options, all specified as string key/value pairs:

 - appname = <appname>

   This is for appdefaults.

 - unique_ccache_type = <TYPE>

   If you want a krb5_cc_new_unique() cache of some type, this is how
   you get it.  (To find the ccache's name though, you need
   gss_store_cred_into2().)

 - ccache = <TYPE>:<residual>

   You can use %{token}s in the <residual>.

 - username : <username>

   This is for determining if the cred to store is "the best" for the
   <username> (i.e., of the form <username>@<user_realm>).

We could easily add one with the same semantics as the krb5.conf option
you proposed for RBCD.  And if the app doesn't set that, the <appname>
can be used to find an appdefault for it.

This is nice because it allows gss_accept_sec_context() to work with the
default credential, GSS_C_NO_CREDENTIAL.

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

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Nico Williams
Removing heimdal-discuss to avoid duplicates.

On Wed, Jun 3, 2020 at 5:30 AM Nico Williams <[hidden email]> wrote:

>
> On Wed, Jun 03, 2020 at 01:29:23AM +0200, Isaac Boukris wrote:
> > On Wed, Jun 3, 2020 at 12:05 AM Nico Williams <[hidden email]> wrote:
> > > On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > > > I'd still love to see an application signal for the service ticket
> > > > using a cred option or name attribute, more likely to help in samba.
> > >
> > > What exactly would the option specify?  I'm certain we can fit it in one
> > > of three different ways though.
> >
> > It could specify the delegation-policy for this creds/context for
> > example, or we can make the ticket always available via
> > name-attributes like Simo suggested, but that would be somewhat
> > unrelated work.
>
> So you're saying you want to be able to say "only accept traditional
> delegated credentials, don't do S4U2Proxy" and also be able to say
> "either is fine"?  And configuration is not enough?  Anyways, my
> preference for that is to use gss_acquire_cred_from().

Yeah, I want a way to override the krb5.conf defaults, when the app
knows exactly what it wants, and wants to know what it gets.

I think context option would have been more adequate if we had, but
cred-based is fine too.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Nico Williams
On Wed, Jun 3, 2020 at 6:53 AM Nico Williams <[hidden email]> wrote:

>
> On Tue, Jun 02, 2020 at 10:30:47PM -0500, Nico Williams wrote:
> > On Wed, Jun 03, 2020 at 01:29:23AM +0200, Isaac Boukris wrote:
> > > On Wed, Jun 3, 2020 at 12:05 AM Nico Williams <[hidden email]> wrote:
> > > > On Tue, Jun 02, 2020 at 08:35:14PM +0200, Isaac Boukris wrote:
> > > > > I'd still love to see an application signal for the service ticket
> > > > > using a cred option or name attribute, more likely to help in samba.
> > > >
> > > > What exactly would the option specify?  I'm certain we can fit it in one
> > > > of three different ways though.
> > >
> > > It could specify the delegation-policy for this creds/context for
> > > example, or we can make the ticket always available via
> > > name-attributes like Simo suggested, but that would be somewhat
> > > unrelated work.
> >
> > So you're saying you want to be able to say "only accept traditional
> > delegated credentials, don't do S4U2Proxy" and also be able to say
> > "either is fine"?  And configuration is not enough?  Anyways, my
> > preference for that is to use gss_acquire_cred_from().
>
> I'll take that back!  The right interface for this is
> gss_store_cred_into() or gss_store_cred_into2().
>
> Here's the idea:
>
>  - you always get a deleg_cred_handle if one was delegated or S4U2Proxy
>    is available,
>
>  - you tell gss_store_cred_into() about what you're willing to store and
>    with what options,
>
>  - if you say "only real creds" then gss_store_cred_into() will not
>    store S4U2Proxy creds.

This sounds a lot of application logic, and we also don't want to
implicitly delegate a ticket at this point.

btw, we don't have to call it s4u2proxy creds, it's just a tgt-less
cache with a service ticket, maybe we could use it in different
manners as well (for local auth, or maybe invent a way to authenticate
to the kdc with it?).
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Greg Hudson
On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <[hidden email]> wrote:
>
> The second half of the problem is a facility for using a "just the
> service ticket" credential to do S4U2Proxy.  Since S4U2Proxy requires a
> host TGT, this has to be done via a privileged service running on the
> host.  I think there is general agreement that this should be done via
> the existing gss-proxy facility unless we run into a roadblock.

To me, gss-proxy sounds like a big requirement, I was hoping for a
simpler plugable client helper mechanism, that simply talks to a
daemon when needed and puts the ticket in cache for the client to use.
In other words, I'd prefer that we define how gss-proxy and other
daemon would be able to achieve this with gssapi, rather than the
other way around.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Simo Sorce-3
On Wed, 2020-06-03 at 16:11 +0200, Isaac Boukris wrote:

> On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <[hidden email]> wrote:
> > The second half of the problem is a facility for using a "just the
> > service ticket" credential to do S4U2Proxy.  Since S4U2Proxy requires a
> > host TGT, this has to be done via a privileged service running on the
> > host.  I think there is general agreement that this should be done via
> > the existing gss-proxy facility unless we run into a roadblock.
>
> To me, gss-proxy sounds like a big requirement, I was hoping for a
> simpler plugable client helper mechanism, that simply talks to a
> daemon when needed and puts the ticket in cache for the client to use.
> In other words, I'd prefer that we define how gss-proxy and other
> daemon would be able to achieve this with gssapi, rather than the
> other way around.

What is gss-proxy?
A pluggable helper client mechanism with that simply talks to a daemon
when need and puts a ticket in the client ccache.

So I am confused at your claim that gss-proxy is "a big requirement"
while at the same time describing a mechanism that is equivalent.

Sure, if you build something that is precisely targeted at resolving
this specific use case, you could build a somewhat smaller "plugin"
infrastructure, with a smaller plugin and a somewhat smaller daemon,
but you'd have to do this from scratch and it would be likely
incompatible with gss-proxy.

Besides, if you look at gss-proxy code you'll see it is not really
"big". The protocol the proxy describes is also well defined so you are
not even forced to use the same implementation if, for some reason, you
want to build something different.

Finally you do not even have to use gss-proxy or a plugin at all.
Assuming we get a way to just store the client provided ticket from the
acceptor you can build your own privileged daemon and a client utility
to achieve the desired goal this way:

Prerequisite:
1. service uses new configuration to store service ticket in ccache1

Additional steps compared to normal gssapi client:
2. custom client tool uses ccache1 to establish a context over a local
socket to a privileged daemon.
3. privileged daemon use access to service keytab to redo a context
establishment but uses usage=BOTH in acceptor to crate a s4u2proxy
enabled delegated credential
4. once the context is established client send the target service they
want a ticket for in the channel
5. privileged daemon performs an init_sec_context with the provided
name to cause gssapi to get a ticket for that target from the kdc
(alternatively privileged daemon can also use krb5 apis directly).
6. privileged daemon sends back a ccache where only the target ticket
is stored.
7. client receives the ccache with the target ticket and stores it in
ccache1.

Regular gssapi client:
8. Client uses ccache1 (now with target ticket) to connect to target as
usual.


So this is all doable with custom code if you want, or you can let gss-
proxy do it for you, you definitely have choice.
The difference is that if you build a custom tool you will have to
explicitly use it before running your original client code, if you use
gss-proxy instead you can use unmodified clients and just set up some
configuration,
Of course we also need a modification to gss-proxy code to implement
the new scheme which is analogous to the steps above (only that it is
done transparently because of the gss-proxy mechglue plugin).


HTH,
Simo.


--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc




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

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Isaac Boukris
On Wed, Jun 03, 2020 at 02:15:58PM +0200, Isaac Boukris wrote:

> On Wed, Jun 3, 2020 at 6:53 AM Nico Williams <[hidden email]> wrote:
> > Here's the idea:
> >
> >  - you always get a deleg_cred_handle if one was delegated or S4U2Proxy
> >    is available,
> >
> >  - you tell gss_store_cred_into() about what you're willing to store and
> >    with what options,
> >
> >  - if you say "only real creds" then gss_store_cred_into() will not
> >    store S4U2Proxy creds.
>
> This sounds a lot of application logic, and we also don't want to
> implicitly delegate a ticket at this point.

On the contrary, this makes the app simpler because configuration now is
something of a hole: the app doesn't need to know anything about it, it
just passes through settings from a config file.

We do this in our sshd already, so it won't need _any_ changes in order
to use this new configuration parameter.

> btw, we don't have to call it s4u2proxy creds, it's just a tgt-less
> cache with a service ticket, maybe we could use it in different
> manners as well (for local auth, or maybe invent a way to authenticate
> to the kdc with it?).

I'm going to call them S4U2Proxy creds.  To me that's what they are.  It
tells me what I need to know: that initiator credentials for the service
are needed.

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

Re: Alternative proxy-creds API for constrained-delegation

Nico Williams
In reply to this post by Isaac Boukris
On Wed, Jun 03, 2020 at 04:11:08PM +0200, Isaac Boukris wrote:
> To me, gss-proxy sounds like a big requirement, I was hoping for a
> simpler plugable client helper mechanism, that simply talks to a
> daemon when needed and puts the ticket in cache for the client to use.

That's still a proxy.  We talked about this on the call.  Love had
wanted all of these proxies back in 2012, and I agree with that:

 - krb5_get_credentials() proxy

 - krb5_mk/rd_req*() proxy

 - gss proxy

All of these can be in the same or different programs -- it doesn't
matter much.

In Heimdal, kcm could be this proxy.

> In other words, I'd prefer that we define how gss-proxy and other
> daemon would be able to achieve this with gssapi, rather than the
> other way around.

The use of a proxy is an internal detail that MUST NOT leak into the
API.  (It's OK if there's a configuration knob in the API for some of
this, but it must not be required that the app know how to use it.)
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Simo Sorce-3
On Wed, Jun 3, 2020 at 4:44 PM Simo Sorce <[hidden email]> wrote:

>
> On Wed, 2020-06-03 at 16:11 +0200, Isaac Boukris wrote:
> > On Tue, Jun 2, 2020 at 8:11 PM Greg Hudson <[hidden email]> wrote:
> > > The second half of the problem is a facility for using a "just the
> > > service ticket" credential to do S4U2Proxy.  Since S4U2Proxy requires a
> > > host TGT, this has to be done via a privileged service running on the
> > > host.  I think there is general agreement that this should be done via
> > > the existing gss-proxy facility unless we run into a roadblock.
> >
> > To me, gss-proxy sounds like a big requirement, I was hoping for a
> > simpler plugable client helper mechanism, that simply talks to a
> > daemon when needed and puts the ticket in cache for the client to use.
> > In other words, I'd prefer that we define how gss-proxy and other
> > daemon would be able to achieve this with gssapi, rather than the
> > other way around.
>
> What is gss-proxy?
> A pluggable helper client mechanism with that simply talks to a daemon
> when need and puts a ticket in the client ccache.
>
> So I am confused at your claim that gss-proxy is "a big requirement"
> while at the same time describing a mechanism that is equivalent.

The gss-proxy isn't just that, it can also interpose the acceptor and
could have solved this problem in many other ways by its own (as you
said yesterday), that by itself qualifies it as big tool for this
problem.

> Sure, if you build something that is precisely targeted at resolving
> this specific use case, you could build a somewhat smaller "plugin"
> infrastructure, with a smaller plugin and a somewhat smaller daemon,
> but you'd have to do this from scratch and it would be likely
> incompatible with gss-proxy.
>
> Besides, if you look at gss-proxy code you'll see it is not really
> "big". The protocol the proxy describes is also well defined so you are
> not even forced to use the same implementation if, for some reason, you
> want to build something different.
>
> Finally you do not even have to use gss-proxy or a plugin at all.
> Assuming we get a way to just store the client provided ticket from the
> acceptor you can build your own privileged daemon and a client utility
> to achieve the desired goal this way:
>
> Prerequisite:
> 1. service uses new configuration to store service ticket in ccache1
>
> Additional steps compared to normal gssapi client:
> 2. custom client tool uses ccache1 to establish a context over a local
> socket to a privileged daemon.
> 3. privileged daemon use access to service keytab to redo a context
> establishment but uses usage=BOTH in acceptor to crate a s4u2proxy
> enabled delegated credential
> 4. once the context is established client send the target service they
> want a ticket for in the channel
> 5. privileged daemon performs an init_sec_context with the provided
> name to cause gssapi to get a ticket for that target from the kdc
> (alternatively privileged daemon can also use krb5 apis directly).
> 6. privileged daemon sends back a ccache where only the target ticket
> is stored.
> 7. client receives the ccache with the target ticket and stores it in
> ccache1.

Yeah that's roughly the picture I have, although 5-7 steps aren't well
defined, but I'm fine with this basis.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Nico Williams
On Wed, Jun 3, 2020 at 5:58 PM Nico Williams <[hidden email]> wrote:

>
> On Wed, Jun 03, 2020 at 02:15:58PM +0200, Isaac Boukris wrote:
> > On Wed, Jun 3, 2020 at 6:53 AM Nico Williams <[hidden email]> wrote:
> > > Here's the idea:
> > >
> > >  - you always get a deleg_cred_handle if one was delegated or S4U2Proxy
> > >    is available,
> > >
> > >  - you tell gss_store_cred_into() about what you're willing to store and
> > >    with what options,
> > >
> > >  - if you say "only real creds" then gss_store_cred_into() will not
> > >    store S4U2Proxy creds.
> >
> > This sounds a lot of application logic, and we also don't want to
> > implicitly delegate a ticket at this point.
>
> On the contrary, this makes the app simpler because configuration now is
> something of a hole: the app doesn't need to know anything about it, it
> just passes through settings from a config file.
>
> We do this in our sshd already, so it won't need _any_ changes in order
> to use this new configuration parameter.

Not sure I follow, so your sshd won't need any changes, how does that
make it simple for others? And again, we don't want to implicitly
delegate a ticket at this point.

> > btw, we don't have to call it s4u2proxy creds, it's just a tgt-less
> > cache with a service ticket, maybe we could use it in different
> > manners as well (for local auth, or maybe invent a way to authenticate
> > to the kdc with it?).
>
> I'm going to call them S4U2Proxy creds.  To me that's what they are.  It
> tells me what I need to know: that initiator credentials for the service
> are needed.

That's what they are now, but I think we can make other uses of it as
pointed out.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Alternative proxy-creds API for constrained-delegation

Isaac Boukris
In reply to this post by Nico Williams
On Wed, Jun 3, 2020 at 6:01 PM Nico Williams <[hidden email]> wrote:

>
> On Wed, Jun 03, 2020 at 04:11:08PM +0200, Isaac Boukris wrote:
> > To me, gss-proxy sounds like a big requirement, I was hoping for a
> > simpler plugable client helper mechanism, that simply talks to a
> > daemon when needed and puts the ticket in cache for the client to use.
>
> That's still a proxy.  We talked about this on the call.  Love had
> wanted all of these proxies back in 2012, and I agree with that:
>
>  - krb5_get_credentials() proxy
>
>  - krb5_mk/rd_req*() proxy
>
>  - gss proxy
>
> All of these can be in the same or different programs -- it doesn't
> matter much.

Proxy is fine, as long as we define its requirements for *this* feature.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
12