Keytab-based initiator creds design

[Nico Williams]

On Thu, May 31, 2012 at 2:44 PM,  <ghudson at mit.edu> wrote:
> For 1.11, we would like to add a feature where gss_init_sec_context
> can be used with a keytab instead of a ccache.  This would eliminate
> the need for k5start or similar tools in many situations.

Yay!  It's about time...  (Solaris has long had partial
init-from-keytab support, but only for processes running as root.)

> I want to discuss the following design points:
>
> * How should we decide to use the keytab?  Heimdal tries to use a
>  keytab whenever there is no ccache in the collection for the desired
>  principal, or if the default ccache doesn't exist
>  (krb5_cc_get_principal returns nonzero).  I think that's reasonable,
>  although see below about caching.

+1

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

I think the Heimdal behavior is useful, actually, but I'd want it to
be more of a list of things to try, such as:

1) If KRB5_PRINCIPAL is set in the environment use that, and if no
keys are found then fail;

2) GSS_C_NT_USERNAME with getpwuid(geteuid()) as the name;

3) if there are no keys for (1) then use the principal name of the
first keytab entry.

Another possibility is to try *all* principals for which there are
keys.  Since you'll almost always be doing this in
gss_init_sec_context() you'll have the target's name, and you can then
handle disjoint forests automatically.  Of course, if you'll do this
it'd be nice if the several attempts could run in parallel.  Also,
there's a privacy issue: clients would be disclosing to various realms
the names of the target principals they want to talk to.

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

This could be configurable, but the default should probably be to
store the credential in a ccache, yes.  But note that if KRB5CCNAME is
not set and there are no PAGs/keyrings/... to leverage then you must
default to a standard ccache naming convention.  But I think that's
fine, particularly if we can use /run/krb5/$USER/ccache.  The cc
config variable idea is a good one.

> There are a few interactions with other features to worry about:
>
> * IAKERB: When the mech is IAKERB, we have to defer the AS request
>  until gss_init_sec_context and use IAKERB to perform it.  Most of
>  the code is already there for gss_acquire_cred_with_password.

You have to be able to defer the AS request until
gss_init_sec_context() anyways, since most of the time clients use
GSS_C_NO_CREDENTIAL anyways.  There's very few non-test code uses of
gss_acquire_cred(desired_name = GSS_C_NO_NAME).

> * Cache collections: if we use the keytab to get a cred and store it
>  in a cache collection, that cache won't necessarily become the
>  default cache.  So when there's no desired name, I think we'll have
>  to do something like:
>  - Look for creds in the default ccache
>  - Pick a client principal based on the keytab
>  - Look again in the collection for a cache for that principal
>  - If we still haven't found creds, make a keytab AS request

See above.  Among other things a KRB5_PRINCIPAL env var might be
useful (though I shudder as I suggest the use of new env vars).
Another thing is that you could try *all* principals for which there
are keys.  Again, see above.

Nico
--