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.

New Credential Cache Collection schema

All KEYRING types become collection enabled, the only difference between the various types is where the ccache keyrings are linked into. Each credential cache in the collection has a name of the form: krb_ccache_XXXXXX where XXXXXX is a random string and the name of the currently active ccache is stored into a key named krb_ccache:primary

All ccache keyring are furthemore stored in a keyring named fater the <name> part of the residual for keyring ccache of thread,process,session,user types, while in the case of the persistent keyring a keyring named _krb is created under the persistent keyring. For backwards compatibility reason on runtime upgrade the classic session keyring type (the one identified by KWYRING:<name>) uses the <name> part of the residual for the first ccache, so all the other ccache reside directly in the session keyring alongside the first one.

The format of a single ccache keyring is unchanged from the classic scheme.

Examples: KRB5CCNAME=KEYRING:testccache

session
 \_ testccache
     \_ __krb5_princ__
     \_ krbtgt/TEST.KERBEROS.ORG@TEST.KERBEROS.ORG
     \_ ...
 \_ krb_ccache_WQRQWTQ3
 \_ ...
 \_ krb_ccache:primary (points to testccache at collection cration)

KRB5CCNAME=KEYRING:user:testusercc

user
 \_ testusercc
     \_ krb_ccache_12WEF43f2
         \_ __krb5_princ__
         \_ krbtgt/TEST.KERBEROS.ORG@TEST.KERBEROS.ORG
         \_ ...
     \_ krb_ccache_fdgsER324
     \_ ...
     \_ krb_ccache:primary (krb_ccache_12WEF43f2)

KRB5CCNAME=KEYRING:persistent:123

_persistent.123
 \_ _krb
     \_ krb_ccache_12WEF43f2
         \_ __krb5_princ__
         \_ krbtgt/TEST.KERBEROS.ORG@TEST.KERBEROS.ORG
         \_ ...
     \_ krb_ccache_fdgsER324
     \_ ...
     \_ krb_ccache:primary (krb_ccache_12WEF43f2)