Preliminary discussion: DB alias entries

[Nicolas Williams]

On Thu, Mar 05, 2009 at 10:04:16AM -0500, Sam Hartman wrote:
> Greg, if you do something like what you are talking about, I think
> Love's approach is the best: a separate key space for aliases.  I
> understand there will be multiple lookups but I think that's OK. 

I agree.  Multiple lookups are not an issue unless they can block a
single-threaded KDC (e.g., imagine using DNS lookups here).

> However, I'd like to ask you to think about whether adding alias
> support to db2 done this way makes any sense at all.  If you have a
> major sponsor who really wants aliases in db2 manipulated through
> kadm5, then by all means go forward.  What you are proposing is not
> harmful; it just seems like something that very few people will find
> useful and thus is likely to be an inefficient use of the consortium's
> time.  Here's why I say that.

Storing aliases in the KDB is almost certain to lead to double entry
procedures for hostname aliases.  Like Sam I'm not sure that's a good
idea -- it's OK as an option, but not OK as the only option unless...

...there's a process for synchronizing alias information in the KDB with
a customer's primary source (or DNS, but handled securely).  In other
words, I'm arguing for any reasonable variant of Sam's "SQLite3 DB
loaded from DNS zone files" option, including that option too.

Using the LDAP backend doesn't seem like a great idea because it's
likely in some cases that the LDAP backend's DIT will be separate from
the primary DIT for the realm, in which case we're back to double entry
or synchronization, and even if the backend is using the realm's DIT we
still have the problem that full host and aliasing data might not be
present in it.

The one common denominator is that almost every environment using
Kerberos V also uses DNS.  So I think we're looking for any reasonable
variant of Sam's "SQLite3 DB loaded from DNS zone files" or any solution
using DNS securely:

 * Look in specific DNS domainnames using a _local_ nameserver.  Don't
   use recursive queries, don't follow delegations, ...  If the
   canonical name of an alias is not found immediately, then stop
   looking.

   A KDC admin can probably arrange to replicate DNS data to a server
   private to the KDC.

   I don't terribly love this -- it's exactly what I would want in terms
   of avoiding double entry and in terms of how easy it is to arrange
   this, but in so far as one could misconfigure the system to do the
   lookups on a public, caching server, it scares me.

 * Have the KDC do DNS zone transfers (secured somehow) of relevant
   zones (the base domainnames can be determined from the contents of
   the KDB) and then load them in a DB.

 * Use DNSSEC (and multi-thread krb5kdc or re-factor it to be async, and
   since the standard resolver APIs are not async, do the DNS lookups in
   worker threads).

Nico
--