logo_kerberos.gif

Difference between revisions of "Projects/HDBBridge"

From K5Wiki
Jump to: navigation, search
(Status)
(Background)
Line 9: Line 9:
 
* allow applications with complex HDB backends, such as Samba4, to use the MIT KDC without porting to KDB
 
* allow applications with complex HDB backends, such as Samba4, to use the MIT KDC without porting to KDB
 
* allow kdb5_util to dump a Heimdal database for migration to a native MIT KDB backend
 
* allow kdb5_util to dump a Heimdal database for migration to a native MIT KDB backend
  +
  +
Additionally, a customer may choose to run the MIT KDC with a Heimdal backend as an interim measure to test compatibility before a full migration. Using, for example, Heimdal's LDAP backend it would be possible for a realm to contain mixed KDCs sharing the same data.
   
 
==Architecture==
 
==Architecture==

Revision as of 17:41, 18 October 2009

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.



Background

This project extends MIT Kerberos with the capability to dynamically load Heimdal database (HDB) backends. The intent is twofold:

  • allow applications with complex HDB backends, such as Samba4, to use the MIT KDC without porting to KDB
  • allow kdb5_util to dump a Heimdal database for migration to a native MIT KDB backend

Additionally, a customer may choose to run the MIT KDC with a Heimdal backend as an interim measure to test compatibility before a full migration. Using, for example, Heimdal's LDAP backend it would be possible for a realm to contain mixed KDCs sharing the same data.

Architecture

A new KDB database plugin, HDB, acts as a bridge between KDB and HDB. Upon instantiation, in dynamically loads Heimdal's HDB library and maps KDB methods to their HDB equivalents.

The bridge also has the ability to bridge policy checking and authorization data signing methods to Heimdal's windc plugin SPI.

Implementation

Code is in plugins/kdb/hdb. Because the bridge needs to dynamically load Heimdal libraries anyway, there is no support for building the bridge statically. The platform needs to support RTLD_LOCAL (or equivalent), otherwise there will be symbol conflicts between the two Kerberos implementations.

hdb

One interesting issue is support for master keys. Both Kerberos implementations are similar conceptually, however the interface for reading master keys is not exposed by libhdb and the encryption algorithms differ. This has the following implications:

  • the dbekd_decrypt_key_data and dbekd_encrypt_key_data implementations by default forward to hdb_unseal_key and hdb_seal_key, respectively
  • methods to return a master key return an empty key with ENCTYPE_NULL, on the presumption this is preferable to poking inside internal Heimdal data structures
  • when dumping a Heimdal database with kdb5_util, the -mkey_convert option must be specified; without this the resulting output is useless
  • as a special case to support the above, when the dbekd_encrypt_key_data method is called with a non-NULL master key, the default MIT implementation is used

windc

In addition to HDB, Heimdal support a "windc" plugin that implements methods for MS PAC generation, signing, as well as AS-REQ authorization. We could have wrapped the former inside an authdata plugin, but in order to support the latter, all methods are in the HDB bridge. The windc shim is loaded only when the backend is opened with KRB5_KDB_SRV_TYPE_KDC usage.

A windc plugin exposes the following methods:

  • pac_generate
  • pac_verify
  • client_access

The first two are handled by the SIGN_AUTH_DATA KDB invoke method; the latter by CHECK_POLICY_AS.

SIGN_AUTH_DATA

Simplified pseudo-code follows (refer to the actual code for details, as there are some special cases to deal with constrained delegation, retrieving the correct TGS key, the inbuilt vs. the windc plugin's pac_verify functions, etc).

sign_auth_data
{
    if (!is_as_req)
        pac ::= find existing authdata from TGT

    if ((is_as_req && (flags & INCLUDE_PAC)) ||
        (pac == null && client != null))
    {
        pac ::= pac_generate()
    }
    else
    {
        pac_verify(pac)
    }
    pac_sign(pac)
    encode_authdata_container(pac)
}

CHECK_POLICY_AS

Simplified pseudo-code follows. The bulk of the actual implementation is concerned with marshalling MIT to Heimdal data structures.

check_policy_as
{
    client_access()
}

Open issues

  • When marshalling the KDC_REQ to pass to the windc client_access method, the following fields are not marshalled: padata, enc_authorization_data and additional_tickets.

Status

Code is in the users/lhoward/heimmig branch. Presently I have only tested with the HDB flat file backend.