Re: Alternative proxy-creds API for constrained-delegation

Nico Williams <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.devel
Message-ID <20200603045250.GW7856@localhost>
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 <[email protected]> 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             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.