Keytab-based initiator creds design

[Nico Williams]

On Fri, Jun 8, 2012 at 10:41 AM, Greg Hudson <ghudson at mit.edu> wrote:
> This system relies on several new UI and API elements:
>
> 1. The client keytab (as distinct from the acceptor keytab):
> * A new environment variable (e.g. KRB5_CLIENT_KTNAME)

Well, I didn't propose that, but sure, new env vars that are not
required for the feature to be usable are fine.

> * A new profile relation containing a search path

Which I expect never to be used outside of tests.

> * A new build-configured default search path

The intention is that vendors define the correct search path(s) for
their OSes.  I'm not sure that the paths need to be configurable via
./configure, but that'd be fine with me.  In fact, I'd rather it be
hard-coded by vendors and autoconf discovered in all other cases.

> * Within the search path, a syntax for expanding parameterized keytab names,
> where the parameters can be (at least) uid/username and session PID

This was implied, yes.

> * Perhaps new krb5 (and maybe gss-krb5) APIs to set the client keytab name
> for a context

I don't see a need for them, but am not opposed.

> 2. The client keytab default principal:
> * We could simplify by saying this is just the principal of the first entry
> in a client keytab
> * Otherwise, all of the above elements again

Yes.

> 3. The client keytab ccache:
> * A new environment variable

I think I'd rather add semantics to existing env vars wherever the
surprise factor would be low.  This one you propose makes me nervous:
it'd have to point to the same ccache where the library will look for
tickets anyways, so I think this one really should not be added as it
adds very little to KRB5CCNAME: just control over whether to write
keytab-acquired creds to the default ccache.

> * A new profile relation containing a search path
> * A new build-configured default search path (distinct from the client
> keytab default search path)
> * Within the search path, a syntax for expanding parameterized ccache names

See comments above about these items for keytab.

> * A new concept of "container existence" for a ccache name, so that we can
> decide whether to use each ccache name in the search list

Yes, so that we do what users would expect, which is: wherever you got
the keytab, write the creds to the most-specific possible ccache.
Here "possible" means: without having to mkdir() missing directories.

> * Perhaps new krb5 (and maybe gss-krb5) APIs to set the client keytab ccache
> name for a context

I have no need for such APIs.

> My concerns about Nico's proposal and variations of it are:
>
> * I don't see how to make it work with cache collections (if a daemon uses
> multiple principals from a client keytab, via desired_name or cc_select).
>  Recall that we don't have first-class cache collections; instead we just
> have a global "the collection", whose contents are partly determined by the
> default ccache name for the library context. So we can't just say there's a
> separate collection for caches derived from the client keytab in a different
> place.  It might wind up that the only way to make that case work is to
> stuff multiple client TGTs into the same ccache, which would be a little sad
> after going to so much effort to avoid that with cache collections.

This sounds like a flaw in the cache collection concept.  But it also
sounds to me like it can be fixed by adding a function to find the
correct ccache given a principal name.

> * The concept of ccache container existence only seems meaningful for FILE
> ccaches, as FILE is the only ccache type with a hierarchical namespace.

It can easily be meaningful for daemon-based ccaches as well, either
in a very simple way ("is the daemon reachable?") or sightly more
complex (add a concept of container to the daemon).  Note that there's
generally going to be at most two items in the ccache search list
(per-session, per-user), so this need not be difficult (if there could
be 10 items in the search list then we'd likely really need a concept
of container in the daemon).

> * The concept of the client keytab ccache is inherently a bit confusing.
>  Calling this a "per-user ccache" as Nico did does not help at all, since
> the existing UI concept of the default ccache already has a per-user
> default.

I never proposed a ccache that's separate for writing keytab-acquired
credentials into.  That makes no sense, since the process might then
not look there for cached tickets, which would render the
keytab-acquired ccache rather useless.

Sorry if I was unclear about this earlier.

> * If the client keytab default principal isn't simplified to just "the first
> principal in the client keytab", and instead comes from a file in a parallel
> search path, then there is a lot of potential for getting a default
> principal which wasn't intended to be associated with a client keytab.

I'd proposed a file (or daemon) location for specifying the default
princ name for this.  But seriously, just by separating the keytab for
initiating creds from the system keytab we make it much easier to
ensure that the desired default principal is first in the keytab.

Incidentally, I've used ktutil too many times to re-order principals
in a keytab.  I wonder if MIT could not provide a simpler tool to do
that.

> * The number of new UI/API elements is very large.  Contrary to Nico's
> assertion, I don't think this is at all simple to document or implement.

The number of UI/API elements that will be used in practice is
actually quite small, really, just the per-user persistent keytab
location that I expect RedHat (and hopefully Oracle) to add, and
possibly a "default_principal" file in that same location.  From a
user's perspective nothing else is new.  DItto the sysadmin's
perspective because they will almost never want/need to change the
default search lists as those are provided by the OS vendor.  Indeed,
I'd be OK with the vendor not shipping support for changing these
lists, or even for not having any way to change them other than at
build time [by modifying some header].

> The other potential benefit is that by introducing new UI elements for each
> aspect of the system, the surprise factor is inherently reduced to zero.

Yes.

>  You can't accidentally draw from the default keytab, or accidentally write
> to the default ccache, if the new feature isn't using those elements.

Well, in my proposal you couldn't write keytab-acquired creds to the
default ccache unless there is a keytab for acquiring creds (a keytab
that must not be the system keytab).  I did not propose a separate
ccache for keytab-acquired and not.

We might want to have a separate keytab for initiator and acceptor
credentials, but I think in practice such a separation will never be
needed -- you can add it if and when you ever turn out to have a user
who needs it.

Nico
--