Difference between revisions of "Projects/Process Credential Management"

Latest revision as of 15:01, 13 October 2009

Use Cases

This project addresses the following use cases:

1. A server-type process needs Kerberos credentials, and possibly also derived credentials (such as AFS tokens) in order to operate. A keytab is available for obtaining credentials. A tool is needed to obtain and re-obtain credentials using the keytab at the intervals necessary to ensure that credentials are always available for the process.

2. A long-running user job, perhaps a large computation, needs credentials (as above) in order to operate. The user can obtain credentials with a renewable lifetime long enough for the job. A tool is needed to renew credentials at the intervals necessary to ensure that credentials are available until the job ends or the renewable lifetime expires.

The following use cases are not in scope (see "discussion of scope" below):

3. A user wishes to ensure that credentials are available for a process or login session for a long time, but cannot obtain credentials with a renewable lifetime that long. A tool is desired to obtain and re-obtain credentials using a remembered password (either in memory or on disk somehow) to ensure that credentials are always available.

4. Automatic or manual credential renewal integrated with the user login process.

Available Code

k5start and krenew, maintained by Russ Allbery, address uses cases 1 and 2 respectively. They are available at http://www.eyrie.org/~eagle/software/kstart/ under licenses similar to the MIT krb5 license. They can operate either as a background process or as a process wrapper; in the latter case, a subsidiary command is specified on the k5start or krenew command line, and the credentials cache is managed as long as the subsidiary process lives (and is then presumably destroyed?). The code for these utilities is based on the kinit code.

Design Options

The only substantially complicated design question is the interface. Once the interface is decided, the code is straightforward and (as noted above) largely already available. A few questions of code organization might remain, particularly if the interface involves multiple programs with highly overlapping option sets. Many of the existing kinit options also apply to uses cases #1 and #2, though at least one (the ticket lifetime) is not meaningfully applicable.

Options for the interface include:

1. Modify kinit's interface to support the additional functionality of both use cases, including the ability to act as a process wrapper.
2. Add the k5start and krenew interfaces as they currently exist, with no changes.
3. Add k5start and krenew interfaces, with changes, such as combining them into a single command, renaming the commands, changing the existing option syntax, or adding options for parity with kinit.

Discussion of Scope

Use case 3 essentially controverts the KDC policy on ticket lifetime and renewable lifetime, and can lead to security compromises if a host is stolen or compromised after it has fallen out of active use. It is worth noting that it can be accomplished in pieces: the user can store his or her long-term key in a keytab and then invoke use case 1. This is perhaps less secure than using a tool which remembers the user's password in memory. So perhaps the in-memory variant of use case 3 should be supported as a lesser of two evils. For the moment, it is out of scope.

Use case 4 is better handled by OS-level tools which can integrate with PAM and/or GUI frameworks.

Current Status

This project has been tabled for the moment. It turns out that kstart contains AFS functionality (setting a PAG) which we would not want to incorporate, and as long as kstart is being maintained, it meets the current needs for process credential management.

If we did a Unix CCAPI port, it might be possible to obtain this functionality in a more natural fashion. Heimdal has something vaguely similar called KCM which can perform automatic renewal.

During discussion, the idea came up of attaching a credential cache to a keytab somehow, such that the krb5 library would automatically perform an AS request to get new credentials when necessary. This idea has the problem that the preauth framework makes AS requests more open-ended than TGS requests; it may not be a great idea for krb5 client programs to start "transparently" performing AS requests instead of relying on an external agent like kinit or a CCAPI/KCM process.