Projects/Credential cache collection improvements

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

This project page is a grab-bag of credential cache collection issues and improvements, some user-visible and some internal. As it proposes only loosely-related internal improvements, it will probably not become a formal project page.

Background

The concept of a credential cache collection began in release 1.6 with the introduction of the krb5_cccol APIs. In release 1.10, the client principal selection project implemented the collection-enabled DIR credential cache type, collection behavior for kinit, klist, and kdestroy, and added the new kswitch command. The behavior of tools on credential cache collections was based largely on the behavior of Heimdal, whose collection semantics in turn were based loosely on Kerberos for Macintosh.

Credential cache types are either collection-enabled (such as DIR) or not (such as FILE). For a collection-enabled type, the residual string may identify a collection (such as DIR:/path/to/directory) or a subsidiary cache within the collection (such as DIR::/path/to/directory/tktXXXXXX). A collection has a primary cache which can be altered by krb5_cc_switch or the kswitch command. Resolving the name of a collection yields a cache whose name is the primary cache within that collection.

If the default credential cache name uses a collection-enabled type, command-line tools behave differently as described in the client principal selection project page. Also, GSSAPI client applications will automatically select client principals based on the $HOME/.k5identity file or the realm of the target server.

The krb5_cccol APIs define "the collection" as the union of all per-type collections. These APIs do not accept the name of a particular collection, but the default ccache name of the krb5_context object influences what is in per-type collections. Except for MEMORY, no ccache type adds caches to the collection unless it is used by the default ccache name. If the default ccache name indicates a subsidiary cache for a collection-enabled type, the ccache type only adds the subsidiary cache to the collection, not the full collection contents.

Possible improvements

Documentation improvements

Collection behavior is described in various parts of the documentation, but there is no documentation dedicated to its use. There is also no documentation of how a ccache type should implementation collection semantics; this documentation would be of internal use only for the moment, but could become public-facing if we implement loadable ccache modules.

Getting credentials for secondary use

"kinit princname" with a collection-enabled default cache switches the primary cache to the newly-obtained credentials. If the credentials are being acquired for secondary use, this is inconvenient, as it typically affects all shells and applications within the login system. There are several common use cases like this: the user may be acquiring root instance credentials for use with specific commands, or credentials in a second realm for use only in contacting servers of that realm.

Heimdal implements kinit --no-change-default which overrides this behavior; we do not yet implement it. Implementing this flag in MIT krb5 would be complicated by the lack of long option support in the Unix versions of our tools. It should perhaps have a short option name anyway for convenience.

Explicitly using secondary credentials for an individual shell command is not as easy as it should be; the user has to use "klist -l" to identify the subsidiary cache name, then set the KRB5CCNAME environment variable to that name. One possible solution is to make kswitch support running a command with KRB5CCNAME set to a subsidiary ccache, instead of switching the primary cache for the collection.

Memory caches

The MEMORY cache type should probably behave like the FILE cache type, adding no caches to the collection except for the default cache if it is a MEMORY cache. Since 1.10, we have not encountered any benefits of adding all MEMORY caches to the collection, and have encountered minor costs (such as ksu having to use a bogus client principal name for its temporary memory cache).

APIs

At least three parts of the system (kinit, ksu, and gss_acquire_cred) decide where to place new credentials for a principal using similar logic. We could provide a library API which implements this logic.

Deciding whether to use collection-enabled semantics currently relies on the result of krb5_cc_support_switch on the cache type. This creates some edge cases which are arguably bugs; for example, if KRB5CCNAME is set to a subsidiary cache name for "kinit princname", kinit will report a confusing error rather than overwriting the cache with a different principal. We could instead introduce a krb5_cc_is_collection API which accepts a ccache name.

If the MEMORY cache behavior is changed as proposed above, then the krb5_cccol APIs, instead of iterating over all types, could call into the cache type of the default cache name, with the residual string as an argument. If krb5_cc_is_collection is implemented, cccursor.c could take care of returning a singleton collection when the default cache name does not indicate a collection. This would simplify the ptcursor_new/ptcursor_next methods of all ccache types and would mean FILE and MEMORY would not have to implement those methods. We could also provide a variant of krb5_cccol_cursor_new which accepts a cache name instead of using the default cache name for the context.

Other discussions

   http://news.gmane.org/gmane.comp.encryption.kerberos.heimdal.general