Projects/Export import cred

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 is to add gss_export_cred and gss_import_cred extensions.

Requirements

The GSS-Proxy project allows GSS operations to be proxied through a daemon. The proxy daemon can be much more robust if it is stateless. To achieve statelessness, the daemon must be able to respond to a caller's gss_acquire_cred() call with an object containing the actual credential information (or a reference to its on-disk representation). For this, we need a way to serialize and deserialize a GSS credential object.

There are two pieces of prior work in this area: an expired internet draft from 2003(draft-engert-ggf-gss-extensions-00) and a Heimdal implementation. The Heimdal API signatures do not match the draft's proposal (Heimdal's signatures are much simpler). We will follow Heimdal's API rather than the draft's. However, we are not required to match Heimdal's token format.

API extensions

The GSS extensions to be implemented are:

   OM_uint32 gss_export_cred(OM_uint32 *minor_status, gss_cred_id_t cred_handle,
                             gss_buffer_t token);
   
   OM_uint32 gss_import_cred(OM_uint32 *minor_status, gss_buffer_t token,
                             gss_cred_id_t *cred_handle);

A mechglue credential containing multiple mech credentials exports to a token containing all of the serialized mech credentials, each tagged so that it can be imported by the proper mechanism. If any of the mechanisms cannot export its mech credential, exporting the mechglue credential fails.

Token format

TODO:

1. Specify mechglue token format

2. Specify SPNEGO token format as mechglue token format

3. Specify krb5 token format

NOTES:

• Heimdal's mechglue token format is <mech oid><mech token> repeated for each mech, where the mech oid and mech token are each represented as a four-byte length followed by the content.

• Heimdal's krb5 token format begins with a four-byte tag which is 0 for a memory ccache and 1 for anything else. If the tag is 0, it is followed by a serialization of the TGT from the cache (the serialization is performed by krb5_store_creds() and krb5_ret_creds()). If the tag is 1, it is followed by the full name of the ccache, which is assumed to be in external storage. Only initiator creds are supported.

Design

TODO: outline code alterations