Realm lookups again

[Nicolas Williams]

On Wed, Oct 01, 2008 at 03:44:04PM -0400, ghudson at MIT.EDU wrote:
> I've been asked to look at
> https://krbdev.mit.edu/rt/Ticket/Display.html?id=6031 which is the
> patch from Mark Phalan at Sun to implement new algorithms for
> determining the default domain and the domain of a realm.  I've
> reviewed some mailing list conversations from April and July
> pertaining to the issue.
> 
> I have two questions for the list related to the patch:
> 
> 1. Right now we have some DNS support for determining default realms
> and host realms (using _kerberos.domain TXT records, not heuristics),
> but it's off by default.  The Sun patch does its DNS heuristics by
> default (in fact, precisely when dns_lookup_realm is false).  Sam
> suggested that there are security issues if an attacker is able to
> forge the default realm, such as possibly convincing ksu not to
> perform a keytab lookup.

The heuristic in the ticket does not depend on _kerberos.domain TXT RRs,
nor does it depend on DNS for the (lookup_kdcs(realm) part if DNS
lookups for KDCs are not enabled.  I can't see the patch, and I don't
think this is in OpenSolaris, so I can't speak to what's in the patch.

For the host->realm heuristic in the ticket there is an attack in that
the ability to spoof NXDOMAIN replies can cause a client to think that a
host's realm is one that is higher up in the chain.  But this is only
true if DNS lookups of KDCs is enabled.

The heuristic host2realm(foo.bar.example.com) can return BAR.EXAMPLE.COM
or EXAMPLE.COM, so an NXDOMAIN spoof attack on
lookup_kdcs(BAR.EXAMPLE.COM) can force the heuristic to return
EXAMPLE.COM.

The severity of such an attack depends on whether you trust EXAMPLE.COM
not to create host-based principals for hosts in bar.example.com.  Now,
with this heuristic this is a determination of trust that one would have
to make for every domain/realm.

It's a pretty good bet that sub-domain/sub-realm relationships imply
that that the child domain/realm trusts the parent not to attack it
willfully.  "Willfully" is a key word there; the parent might be
compromised and forced to attack the child.

Enabling DNS lookups of KDCs does make it easier to attack
PA-ENC-TIMESTAMP, something that is much more of a concern for me (of
course, one could use DNS for lookup_kdcs() in the host2realm() path,
but not in the AS exchange path).

> Is there any way to resolve the desire for zero-configuration with the
> security concern about using DNS for default realm determination?

I think an interesting question is where this host2realm() heuristic
should stop by default.  If you make it stop at (label_count(host.fqdn)
- 1) then there's no possibility of spoofing, but in the above example
you'd need a domain_realm entry if BAR.EXAMPLE.COM does not exist.  So
you can have this heuristic on but with a default tunable that makes it
immune to NXDOMAIN spoofing.

A realm-join-time heuristic could also be added where the client can see
for itself that the realm is not a direct mapping of its domain.  "I'm
in bar.example.com but my realm is EXAMPLE.COM, so assume that there's
no sub-realms of EXAMPLE.COM and create a suitable domain_realm
relation."

> 2. To use our shiny new DNS host->realm heuristic for the local
> default realm, we need a list of domain names to apply the heuristic
> to.  The patch iterates over two lists of domain names:
> 
>   * The result of res_gethostbyaddr on each interface IP address
>   * Each entry in the DNS search path
> 
> I have concerns about the portability of this code as supplied, and
> more generally about our ability to portably determine the DNS search
> path.

MIT krb5 already has plenty of #ifdef'ed code for things like interface
address lookups, and already uses the BIND 8 resolver C interfaces, and
those are pretty much universal in the Unix/Linux world (including the
default domainname and the search list).  I don't see what could be
added here that would change that situation.

> Would it be sufficient to canonicalize the result of gethostname() and
> apply the heuristic to that?

Quite possibly, but the canonicalization would require access to at
least a default domainname from the DNS resolver.  It also would be
sufficient to determine the default realm from the host's keytab
entries, if it has any, at realm-join time.

> (A brief introduction for those wondering who I am: I've been hired
> into the Kerberos consortium starting this week.  I have some
> familiarity with the krb5 source base going back a decade or so but
> I'm not an expert.  My work will likely focus on improving the
> Kerberos development process in several ways.)

I saw the notice today.  Congratulations!

Nico
--