Hi Tom, Am 2012-09-05 16:01, schrieb Tom Yu: > [email protected] 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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
