Projects/Keyring collection cache

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.

Scope

Implement a new Kernel based credential cache collection that uses the Keys API.

The new cahe type is a collection and is store in a per-user keyring avaialble to any user session and that can persist in the system until expiration time even in the absence of an active user session.

Background and previous work

The MIT Kerberos code base already include a KEYRING ccache type that uses kernel keyrings to implement a credential cache modeled after the FILE cache type. This cache type has 3 important limitations:

• Uses only session or process or thread based keyrings

This means the cache cannot survive a user logout and cannot be shared between different sessions of the same user.

• Uses the classic "user" key type

The "user" keytype is limited in size because use kernel locked memory so it has issues storing large tickets (like those including a MS-PAC AD) due to strict default quotas on this type of key

• It cannot represent cache collections.

Current Keyring cache format

The current implementation creates a new keyring named after the residual and links it to the session/process/thread special keyrings.

This keyring contains one spaecial key named __krb5_princ__ that contain the ccache principal name. Then each credential is stored as a separate key in the same keyring.

Example: KRB5CCNAME=KEYRING:testccache session

\_ testccache
    \_ __krb5_princ__
    \_ krbtgt/TEST.KERBEROS.ORG@TEST.KERBEROS.ORG
    \_ krb5_ccache_conf_data/fast_avail/krbtgt\/TEST.KERBEROS.ORG\@TEST.KERBEROS.ORG@X-CACHECONF
    \_ krb5_ccache_conf_data/pa_type/krbtgt\/TEST.KERBEROS.ORG\@TEST.KERBEROS.ORG@X-CACHECONF
    \_ HTTP/http.test.kerberos.org@TEST.KERBEROS.ORG
    \_ ...

DesignComponents

Linux Kernel improvements

Addition of a new key type "big_key" that allows us to create keys up to 1MiB in size, backed by internal kernel tmpfs, allowing the contents to be swapped out to disk (unlike most other keyrings, which remain in unswappable kernel memory).

Creation of a new public interface, keyctl_get_persistent(uid_t, key_serial_t id). This API allows the user (and certain privileged root processes such as rpc.gssd and GSS-Proxy) to access the keys for a particular UID. This keyring is not tied to a session (so it can outlive a user on the system if there is the need to perform actions while not logged in, such as cron scripts access to Secure NFS). This kernel keyring is created automatically on the first request if it does not yet exist.

Proposed patches by David Howells with explanatory comments on the kernel krbcache keyring: http://mailman.mit.edu/pipermail/krbdev/2013-August/011650.html (note now renamed to 'persistent')

Augmenting the current KEYRING cache type

The current keyring ccache type accepts the following residual forms: KEYRING:<name> KEYRING:process:<name> KEYRING:thread:<name>

Where name is an arbitrary string. The first type implies the use of a session keyring.

libkrb5 will now accept a new values for the ccache name:

KEYRING:session:<name> KEYRING:user:<name> KEYRING:persistent:<uidnumber>

Also all the keyrings will now allow to create cache collections.

The session and user keyrings use the session and user's keyrings. The new persistent type uses a special keyring as provided by the new keyutils call keyctl_get_persistent(). It requires support from the kernel for this new type otherwise it will fallback to use a user type keyring.