Credential collections

[ghudson@MIT.EDU]

We need to decide how, in the core Unix code, to handle credentials
for multiple client principals.  There are three facets to this
problem: API, CLI, and representation.

API
---

Most prior work on this problem has assumed that each ccache is for
one client principal.  This is not actually required by the krb5_cc_*
data model; I think the idea flows mostly from the traditional
behavior of kinit and kdestroy.

We have a krb5_cccol_* API for iterating over all known ccaches;
Heimdal supports that as well (as well as its own
krb5_cc_cache_get_first and krb5_cc_cache_get_next APIs, which operate
on a single type).  The implementation works best with a daemon-backed
ccache type like API or KCM.

The options I can see for ccache lookup from the GSSAPI krb5 code are:

1. Use the krb5_cccol_* API, possibly adding a search operation to
that API.

2. Reject the idea of a cache collection iterator, and just look for
credentials of the desired client principal within the default ccache.

3. Use the richer kim_ccache_* API.  (Requires using KIM for the first
cut implementation, which may require more resources than we have
available for this.)

I personally prefer option 2 except that it ignores previous work.

CLI
---

kinit and kdestroy can be used to manage multiple ccaches using the -c
flag, but it's not very convenient.  The only previous work I'm aware
of in this area is in KfM, which has the following extensions:

* "kinit principal" scans the collection for a ccache for principal,
  and creates a new unique CCAPI ccache if one doesn't exist.

* "klist -A" lists creds for all ccaches in the collection.

* "kdestroy -A" destroys all ccaches in the collection.  "kdestroy -p
  principal" scans the collection for a ccache for principal and
  destroys it.

* "kswitch -c ccname" or "kswitch -p princname" sets the default
  ccache in the collection.  (In the normal case this translates into
  a message to the CCAPI daemon.  When KRB5CCNAME is set the semantics
  are confusing to me and possibly broken.)

The kinit change is substantial; users accustomed to the old behavior
could wind up leaving tickets around.

Options I can see are:

1. Implement the KfM extensions.

2. Implement the KfM extensions, but require a kinit flag to use the
collection.

If we reject the idea of iterating over a cache collection, then the
KfM extensions would need to be adjusted somewhat to make sense.

Representation
--------------

Iteration over ccaches currently works best with a daemon-backed
ccache type.  The daemon acts like a non-persistent filesystem
containing only ccaches, which makes it easy to search.

Unfortunately, we don't have a daemon-backed ccache type in the core
krb5 Unix code yet.  One possible answer is that this whole project
should gate on a CCAPI or KCM implementation for Unix in MIT krb5.  If
we take that as the path, I'm guessing we could get the daemon-backed
ccache done for 1.10, but probably nothing beyond that in the client
identity selection space.

So, some other options:

1. If we reject the idea of iterating over a cache collection, the
representation problem becomes easy; credential collections are just
FILE-format ccache files containing tickets for multiple client
principals.

2. We could create the notion of a ccache which is a
one-client-principal subset of a FILE-format ccache.  krb5_ccol_*
would iterate over the unique client principals of each FILE ccache it
knows about, returning subsets.

There are more and less correct ways of implementing this; the cheesy
approach is to make the subset be the whole FILE ccache with only the
default principal changed.  The cheesy approach works fine for lookup
operations, but initialize, destroy, and iterate operations would leak
over into other client principals.

3. We could create the notion of a per-uid directory of ccaches, and
try to somehow migrate there from the current default ccache names
(typically /tmp/krb5cc_*, often chosen by pam_krb5 or similar).