Turning off hostname canonicalisation

Nicolas Williams Nicolas.Williams at sun.com
Mon Sep 12 17:41:47 EDT 2005

IMO we do need some form of secure name canonicalization as users mostly
can't be bothered to type FQDNs and, anyways, appreciate domain search

There is a simple name canon algorithm that is reasonably seacure that
involves zero protocol work.  There's also Kerberos referrals, which are
more secure.

That algorithm goes like this:

 - find a domain search list (e.g., the one from the local resolver

 - find an authority against which to run the canonicalization
   algorithm; there are multiple options:

    - DNSSEC, if you have it
    - a static list of names, as in a keytab, for example
    - a TGS

 - check to see if the given input name is canonical as is

    - if so, done

 - for each domain name in the search list

    - see if input-name.search-domain is canonical
       - if so, break

 - fail

Canonicalization against DNSSEC is what we're used to, but using DNSSEC.

Canon against a keytab means using the list of principal names in the
keytab as an authoritative complete list (even though it's not, for some
purposes it may be complete enough, e.g., such as when canonicalizing a
name to use to acquire acceptor credentials).

Canon against a TGS means: try a TGS-REQ for a service ticket for each
possible canonical name.  This is more secure than using DNS, but not as
secure as using DNSSEC or not canonicalizing at all -- that's because
KRB-ERROR messages are not authenticated, so an attacker can walk a
client down a search list, but still, this is much better than using DNS
while also user-friendly.

Reverse DNS canonicalization needs to go out the window.  Instead KDCs
and servers need to be aware of aliases.


More information about the krbdev mailing list