Keytab-based initiator creds design

Russ Allbery rra at
Thu May 31 15:59:50 EDT 2012

ghudson at writes:

> * How should we pick the client principal if the application doesn't
>   specify a desired initiator name?  (I think pretty much no
>   applications specify desired initiator names.)  Heimdal assumes a
>   client principal based on your uid (like "ghudson" or "root" or
>   "ghudson/root"), which I don't think is very useful.  My inclination
>   is to use the principal of the first key in the keytab.

We have fairly extensive experience at Stanford with using the "first key"
rule with keytabs, and we're generally happy with it.  However, I think
it's worth the warning that, in practice, it tends to be equivalent to
requiring that every keytab contain keys for one and only one principal.
Whenever a keytab has more than one principal, our experience the first
key rule tends to be wrong.  One obvious reason for this is that most
tools that understand keytabs append new keys to the end of an existing
keytab, so when there are multiple principals represented, the newest one
(and therefore often the more correct one following host renamings) tends
to be the last one.

It might be worth considering a strategy of "last key" instead.

> * How should we store the resulting credential?  Heimdal puts it into
>   a unique memory ccache, which means there's no caching of TGTs even
>   within a process.  Again, I don't think that's great.  The simplest
>   choice is to put the resulting credential into the default ccache
>   (or collection), unless that sounds too surprising.

I think using the default ccache would be a bad idea.  This feature would
be primarily used by system services and other non-user processes, and
those rarely have KRB5CCNAME set and therefore will default to a globally
shared UID-based cache.  This will mean that services with multiple
principals are likely to get confused.

Something unique to that context seems like a better idea.  A keyring
cache bound to the session would probably be ideal for systems that have
such a thing, but that's pretty limited.

> If we do that, though, that ccache will expire N hours later.  We could
> use a config variable to remember that the ccache was obtained
> automatically from a keytab and repopulate it with another AS request if
> (say) it's halfway to being expired.

You want to be sure that your credential renewal strategy tolerates at
least one failure.  We see failures to reauthenticate fairly regularly.
k5start now takes a strategy of retrying every five minutes after a
failure until it gets another success.

Russ Allbery (rra at             <>

More information about the krbdev mailing list