Keytab-based initiator creds design

Simo Sorce simo at redhat.com
Sat Jun 2 16:51:46 EDT 2012


On Sat, 2012-06-02 at 12:50 -0400, Greg Hudson wrote:
> On 06/02/2012 10:05 AM, Sam Hartman wrote:
> > I think you want to be careful about making it too easy for this code to
> > trigger automatically.

I'd like to know what this means ?
Do you have code lying around that tries arbitrarily a
gss_init_sec_context on the off chance it works and then falls back to
something else ?
Although I believe this may exist I do not believe this to be common,
besides you need access to a keytab to boot.

> > Like Russ, I believe storing in the default ccache is problematic and
> > believe that having a robust renewal strategy is important.
> 
> Okay.  Backing off a bit further from the Heimdal model, I have two
> other ideas:
> 
> 1. You have to set KRB5_KEYTAB_PRINCIPAL.  The default ccache or
> collection is used.

Would it make sense to have something in a config file to turn on/off
this feature ?
Relying on an environment variable is probably also ok, but I like the
ability to just set a keytab and not have to worry to change startup
scripts in order to have env vars properly set.

> 2. You have to kinit -k with a new flag and make the resulting ccache
> the default cache.  kinit sets a ccache config var remembering the name
> of the keytab.  The GSS initiator code recognizes this variable and
> tries to refresh the TGT with the keytab if it's more than halfway to
> expired.

This will make the feature almost useless, the point is to be able to
avoid using k5start, if I have to use kinit -k, then I can just as well
keep using things like k5start ...

> Some details: can this also work with kinit -S and do we need additional
> config state to make that happen?  Do we need additional config state to
> avoid trying to refresh too frequently, given that refreshing can fail?

Would it make sense to store an expired ccache entry with a hint about
the number of times a retry was tried ? and implement a backoff scheme
based on that number ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the krbdev mailing list