Projects/Database Access Layer cleanup

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 page describes ideas for cleaning up the KDB Database Access Layer (DAL). No resources or schedule have been assigned to this project yet. It is likely that this project will be narrowed or split out into sub-projects before implementation.

Master key encryption

DB2 and LDAP encrypt key entries in a master key, which is obtained either through password entry at KDC/kadmind startup time or from a stash file. Encryption and decryption of key data is currently performed explicitly in the KDC and libkadm5.

It is possible to construct a database plugin which does not encrypt key data in a master key, but it is hackish: the plugin overrides the default fetch_master_key function to return a dummy key, and overrides the default dbekd_encrypt_key_data and dbekd_decrypt_key_data functions to perform no encryption or decryption.

It would perhaps be cleaner if key encryption and decryption were performed underneath the DAL. Since the user interface features associated with master keys necessarily exist above the DAL, we would still need entry points to implement those features.

db_invoke

As of 1.7, the DAL contains a function named db_invoke, which accepts a method number and a pair of krb5_data objects for "request" and "reply". It is used for a variety of unrelated purposes.

The db_invoke function should be split out into separate, type-safe interfaces; there is no good reason to have a mini-DAL within the DAL.

tl_data

The krb5_db_entry structure contains a field named tl_data, which was originally introduced in order to make the DB2 back end extensible.

The TL-data concept should exist below the DAL, and the krb5_db_entry structure should contain the actual fields represented in TL-data.

krb5_key_data

The krb5_key_data structure is very representation-oriented. It contains a "version" (separate from the kvno) which indicates whether or not there is an explicit salt associated with the key, and then the type/length/contents pointers are arrays of two elements, the second of which determines the explicit salt. This structure should be redefined in a more logical fashion, and the conversion to the format used by the DB2 back end should be performed underneath the DAL.

Alias-related flags

The flags field for db_get_principal does not explicitly indicate whether aliases are okay. (They should be allowed for TGS requests, and for AS requests if the client indicates a willingness to accept them.) Currently the LDAP back end uses a combination of CLIENT_REFERRALS_ONLY and CANONICALIZE to decide whether to return aliases. There should be an explicit flag.

Miscellaneous cleanup

The db_get_principal function takes "nentries" and "more" parameters which are never productively used. A principal name can only have one associated principal.

The db_put_principal function takes a list of krb5_db_entry structures. We never use it to put more than one principal, and we have no expectation of needing transactional updates across principals. It should take only a single krb5_db_entry.

Some krb5_db functions are never used. Since we have no compatibility promises for libkdb across releases, these should be inventoried and removed.