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