Alternative proxy-creds API for constrained-delegation

Nico Williams nico at
Wed Jun 3 00:52:52 EDT 2020

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 <nico at> 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

 - 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.


More information about the krbdev mailing list