On what basis does host canonicalization happen?

[Tom Yu]

1983-01-06 at gmx.net writes:

> I recently tried to answer to stackoverflow question regarding SPN/host canonicalization. While reading the GSS-API and Kerberos 5 RFCs I have found a contradiction which I do not fully understand.

Could you provide a link for this stackoverflow question?

When you say "canonicalization", do you mean resolving aliases, or do
you mean also doing reverse resolution on an address record?  These
are two different (but related) things.

> RFC2713 says on page 85:
>> When a reference to a name of this type is resolved, the "hostname"
>> may (as an example implementation strategy) be canonicalized by
>> attempting a DNS lookup and using the fully-qualified domain name 
>> which is returned, or by using the "hostname" as provided if the DNS
>> lookup fails. The canonicalization operation also maps the host's name 
>> into lower-case characters.
>
> So it is up to the mechanism to lookup the real FQDN. Same does RFC1964.

RFC 2713 does not have 85 pages and appears to be about Java objects
in LDAP.  Are you referring to RFC 2743?

> While RFC4120 says:
>> Implementations of Kerberos and protocols based on Kerberos MUST NOT use
>> insecure DNS queries to canonicalize the hostname components of the 
>> service principal names (i.e., they MUST NOT use insecure DNS queries to 
>> map one name to another to determine the host part of the principal name 
>> with which one is to communicate). In an environment without secure name 
>> service, application authors MAY append a statically configured domain 
>> name to unqualified hostnames before passing the name to the security 
>> mechanisms, but they should do no more than that. Secure name service 
>> facilities, if available, might be trusted for hostname 
>> canonicalization, but such canonicalization by the client SHOULD NOT be 
>> required by KDC implementations.
>>
>> Implementation note: Many current implementations do some degree of 
>> canonicalization of the provided service name, often using DNS even 
>> though it creates security problems. However, there is no consistency 
>> among implementations as to whether the service name is case folded to 
>> lowercase or whether reverse resolution is used. To maximize 
>> interoperability and security, applications SHOULD provide security 
>> mechanisms with names that result from folding the user- entered name to
>> lowercase without performing any other modifications or canonicalization.
>
> I have checked the source code of krb5_sname_to_principal in sn2princ.c and see that it does canonicalize the hostname with DNS.

The canonicalization that krb5_sname_to_principal performs is a
historical artifact that is difficult to change without breaking
existing deployments.  By setting the libdefaults setting "rdns =
false", it is possible to disable the reverse resolution, but not the
forward lookup.

> So, how to interprete that? Kerberos should not lookup in DNS at anytime?
> I use most of the time JGSS and it does canocalize the hostname. This is crucial if you have DNS round-robin.

Deployment scenarios such as DNS round-robin are one of the reasons
why this behavior persists.  We are looking into ways to stop doing
hostname canonicalization.  Having the KDC know all of the aliases of
a hostname and synthesizing principal name aliases would be one way,
but the client library somehow also needs to know when the KDC can
support this.

It is more secure to avoid insecure DNS lookups for canonicalizing
hostnames.  (Local host tables and DNSSEC might be safer, but more
difficult to deploy and maintain.)  It's possible to interpret the
text in RFC 1964 as only requiring forward lookups, but even limiting
DNS lookups to that extent would still result in some vulnerability to
DNS spoofing.  In practice, doing reverse resolution seems to cause
operational problems if forward and reverse DNS zones are not under
the control of the same administrators (which seems to be somewhat
common).