On what basis does host canonicalization happen?

[Michael-O]

Hi Tom,

Am 2012-09-05 16:01, schrieb 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?

http://stackoverflow.com/q/12229658/696632

If you think you can give a more qualified answer, please do so. I am 
always willing to learn more about Kerberos.

> 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.

I mean the latter.

>> 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?

Yes, of course. RFC 2743. This was a typo!

>> 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.

What would be the benefit setting this option? You would still rely on DNS.
How is it done right now if the function is just historic?

>> 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.

So, this is a future outlook but not reality, right? The KDC should give 
answers about IP => hostnames then.
Such an option would turn the KDC into a DNS. Is this really desired?

> 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).
>

For now, I do not see an alternative to a forward and reverse lookup at 
them moment. Well, isn't Kerberos used in managed environments only 
where only a few have control over DNS entries? In my case I am in an 
huge company with thousands of KDC (Active Directory, namely).

Are the aforementioned quotes a contradiction or simply a not solvable 
problem at the moment?

Thanks,

Mike