Keytab-based initiator creds design

[Simo Sorce]

On Thu, 2012-05-31 at 15:23 -0500, Nico Williams wrote:
> 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

+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;

I don't think this makes much sense if you are going to use a keytab, in
this case you pretty much are bound to use whatever key is ni the keytab
so using the principal indicated in the keytab seem to be the best
option. Of course if the keytab has a user principal, then that will be
used.

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

I don't think that trying all principals by default is a good option,
seem wasteful and almost always not what the application wants to do
anyways.

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

I also think that if KRB5CCNAME is not set that we should have a
reasonable default. On Unix systems I would consider a good idea to use
argv[0] (trimmed to the last path component) as part of the ccache name.
It may not be the best choice in cases where script languages are used
(multiple processes ending up with a ccache including
'python/perl/etcc..') but better than using a cache name solely based on
the uid/usernme of the user under which these are running.

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

I am not sure that introducing a KRB5_PRINCIPAL is a good idea.
If you know to set this evn variable then you can as well just give the
app the right keytab containing only the set of keys for the one
principal it should use.

However I am not against it if it is deemed important to make this
mechanism cope with keytabs containing multiple principals keys.

Simo.

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