Revision as of 14:58, 21 August 2013

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

Augment the KEYRING ccache type to support collections, and to support a new type of key which persists across multiple user login sessions until the ticket expires.

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:

It uses only session, 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.
It uses the classic "user" key type. The "user" key type is limited in size because it uses non-swappable memory, so it has issues storing large tickets (like those including MS-PAC authdata) 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 either the session, process, or thread special keyrings.

This keyring contains one special key named "__krb5_princ__" which contains the ccache principal name. Each credential is stored as a separate key in the same keyring. The __krb5_princ__ key and the credential keys use the "user" key type and contain serialized representations of the principal name or credential as appropriate.

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
    \_ ...

Design components

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. This API allows the user or a privileged process to access keys for a specified UID. This keyring is not tied to a session, so it can outlive a login session if there is a need to perform actions while not logged in, via a cron scripts or similar. 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 form implies the use of a session keyring.

libkrb5 will now accept new forms for the residual string:

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

All residual forms will support cache collections.

The session and user keyrings use the session and user keyrings respectively. The new "persistent" form 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 fall back to the user keyring and the "user" key type.

Individual ccaches within the collection are identified and displayed by appending the specific ccache keyring name to the main residual. For example:

 KEYRING:persistent:123:krb_ccache_WE324ffdX

New credential cache collection schema

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

For the "thread", "process", "session", and "user" residual forms, the ccache keyring is stored in a keyring named with the <name> part of the residual and linked into the appropriate special keyring. For the "persistent" form, the ccache keyring is named "_krb" and is linked to the persistent keyring. For backwards compatibility, the classic session residual form (the one identified by KEYRING:<name>) uses the <name> part of the residual for the first cache, and the other caches in the collection reside directly in the session keyring alongside the first one.

The format of a 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)

@@ Line 3: / Line 3: @@
 = Scope =
-Implement a new Kernel based credential cache collection that uses the Keys API.
+Augment the KEYRING ccache type to support collections, and to support a new type of key which persists across multiple user login sessions until the ticket expires.
-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 =
@@ Line 11: / Line 9: @@
 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
+* It uses only session, 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.
-This means the cache cannot survive a user logout and cannot be shared between different sessions of the same user.
+* It uses the classic "user" key type.  The "user" key type is limited in size because it uses non-swappable memory, so it has issues storing large tickets (like those including MS-PAC authdata) due to strict default quotas on this type of key.
-* 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 ==
+== 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.
+The current implementation creates a new keyring named after the residual and links it to either the session, process, or thread special keyrings.
-This keyring contains one spaecial key named __krb5_princ__ that contain the ccache principal name.
+This keyring contains one special key named "__krb5_princ__" which contains the ccache principal name.  Each credential is stored as a separate key in the same keyring.  The __krb5_princ__ key and the credential keys use the "user" key type and contain serialized representations of the principal name or credential as appropriate.
-Then each credential is stored as a separate key in the same keyring.
 Example:
@@ Line 33: / Line 30: @@
      \_ ...
-= DesignComponents =
+= Design components =
 == Linux Kernel improvements ==
-Addition of a new key type "big_key" that allows us to create keys
+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
-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).
-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,
+Creation of a new public interface, keyctl_get_persistent.  This API allows the user or a privileged process to access keys for a specified UID.  This keyring is not tied to a session, so it can outlive a login session if there is a need to perform actions while not logged in, via a cron scripts or similar.  This kernel keyring is created automatically on the first request if it does not yet exist.
-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:
@@ Line 56: / Line 46: @@
 The current keyring ccache type accepts the following residual forms:
 * KEYRING:<name>
 * KEYRING:process:<name>
 * KEYRING:thread:<name>
-Where name is an arbitrary string.
+where <name> is an arbitrary string.  The first form implies the use of a session keyring.
-The first type implies the use of a session keyring.
-libkrb5 will now accept a new values for the ccache name:
+libkrb5 will now accept new forms for the residual string:
 * KEYRING:session:<name>
@@ Line 68: / Line 59: @@
 * KEYRING:persistent:<uidnumber>
-Also all the keyrings will now allow to create cache collections.
+All residual forms will support cache collections.
-The session and user keyrings use the session and user's keyrings respecitively.
+The session and user keyrings use the session and user keyrings respectively.  The new "persistent" form 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 fall back to the user keyring and the "user" key type.
-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.
-Individual ccache are identified and displayed by appending the specific ccache keyring name to the main residual:
+Individual ccaches within the collection are identified and displayed by appending the specific ccache keyring name to the main residual.  For example:
-Example:
- KEYRING:persistent:123:krb_ccache_WE324ffdX
+  KEYRING:persistent:123:krb_ccache_WE324ffdX
-== New Credential Cache Collection schema ==
+== 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.
+All KEYRING types become collection enabled.  The only difference between the various types is where the cache 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
+Each credential cache in the collection has a name of the form "krb_ccache_XXXXXX", where XXXXXX is a unique string.  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.
+For the "thread", "process", "session", and "user" residual forms, the ccache keyring is stored in a keyring named with the <name> part of the residual and linked into the appropriate special keyring.  For the "persistent" form, the ccache keyring is named "_krb" and is linked to the persistent keyring.  For backwards compatibility, the classic session residual form (the one identified by KEYRING:<name>) uses the <name> part of the residual for the first cache, and the other caches in the collection reside directly in the session keyring alongside the first one.
-The format of a single ccache keyring is unchanged from the classic scheme.
+The format of a ccache keyring is unchanged from the classic scheme.
 Examples:

Difference between revisions of "Projects/Keyring collection cache"

Revision as of 14:58, 21 August 2013

Contents

Scope

Background and previous work

Current keyring cache format

Design components

Linux Kernel improvements

Augmenting the current KEYRING cache type

New credential cache collection schema

Navigation menu

Views

Personal tools

Navigation

Search

Tools