Preliminary discussion: DB alias entries

[Greg Hudson]

More status updates on DB alias entries:

* Based on feedback from Sam and others, I prioritized LDAP aliases
ahead of DB2 aliases.

* It turns out that the existing LDAP code already supports multiple
names for an entry, but doesn't know which one is canonical.  I have
working code to add krbCanonicalName to the schema and support for it,
and am just waiting for an OID assignment from the MIT arc for the new
attribute.  (Do I also need to register the name somewhere in some
global LDAP list of names?)

* My very simple plan for introducing db2 aliases may not be as simple
as I hoped.  Our current back end code does not assume that different
processes can share an opened db2 database.  I'm not sure how much of
that is conservatism and how much of that is real.  If we use a second
db2 database for the aliases, that means there has to be a locking
protocol between the KDC and the code to update the aliases DB--which
means you can't use just any old db2 program to update the DB.  I'll
need to think on this some more.

Side issues which came up:

* I discovered that kdb5_ldap_utils had been broken by the merge of
Luke's work and fixed it (though there may be an additional constraint
on how much of krb5.conf has to be set up for kdb5_ldap_utils to work).

* I discovered that our client side support for aliases didn't work in
cases where the client derives the salt from the client principal name.
I've committed a fix for the simple case (no preauth); Sam thinks
further changes are probably necessary for some preauth cases but hopes
to learn more about what those changes are at the interop event.

* If the client principal is canonicalized by the KDC, we are still
prompting for a password using the requested principal name, which is
perhaps undesirable.  This is because the canonicalized name might
contain unprintable characters (either from a malicious KDC or from an
attacker) and I wasn't prepared to add unprintable-sanitization code to
the library at this moment.

Comments welcome as usual.