Keytab-based initiator creds design

ghudson@MIT.EDU ghudson at MIT.EDU
Thu May 31 15:44:53 EDT 2012


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.

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.

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

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

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.

* 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


More information about the krbdev mailing list