bug: krb5_get_host_realm() no longer uses DNS

[Nicolas Williams]

On Thu, May 20, 2010 at 03:23:51PM -0400, Greg Hudson wrote:
> On Wed, 2010-05-19 at 18:29 -0400, Richard Silverman wrote:
> > in my system, DNS TXT records *are* "explicit local configuration."
> 
> They're explicit configuration, but not local to the host machine.
> (They're local to your organization, but that's not the sense in which I
> was using the term.)

Most importantly: lookups of DNS TXT RRs for host2realm mapping are not
DNSSEC-protected in the current code base, nor is it likely that DNSSEC
will be deployed in most Kerberos use cases today (though we all hope
DNSSEC will be widely deployed soon enough).

In the case of localhost->realm lookups for AS exchanges there's little
harm that could come from using DNS TXT RRs if you're also using SRV RRs
to find the KDCs for that realm.  In the case of TGS exchanges to get
service tickets to local host-based principals there's no harm at all
from using localhost->realm lookups.  In all other cases there can
definitely be harm.

> > Perhaps dns_lookup_realm could have more values: "no,"
> > "on_referral_failure," and "always."  I would set "yes" to mean "always"
> > for backward compatibility, but you might want it to be
> > "on_referral_failure."
> 
> I think this is more complexity than you need.  You don't actually need
> DNS records to take priority over referrals; you just want them to apply
> to acceptors--or, more generally, for acceptors to work without local
> configuration of the server realm.

A more complete generalization can be based on what I wrote above.

> I could see us making either of the following changes to use cases like
> yours:
> 
> 1. Bringing the krb5_get_fallback_host_realm() logic back into the
> acceptor case somehow, effectively restoring the 1.5 behavior for
> acceptors.  The most obvious way to do this would, unfortunately, be a

Via a krb5_context flags abstracted via accessor functions!

> pretty clear layering violation--krb5_kt_get_entry should not be
> invoking host-to-realm logic--so this would probably be done within the
> krb5 GSS mechanism code.

I'd expect this to be triggered from the mech, yes.

> 2. Making the referral realm match any realm within keytabs.  With this
> behavior, your servers wouldn't need to consult DNS TXT records to
> determine their own realms (though you'd presumably still need the
> records for the sake of initiators), eliminating a denial of service
> spoofing attack.  Sam did not like this option back in 1996, although I
> don't fully understand his objection:

This doesn't work for non-privileged apps, but it'd work for sshd.

>         One option would be to match any realm if you get a null realm
>         principal in the keytab code.  I dislike this option a lot even
>         though I think Doug would like it.  The problem is that you get
>         behavior that might encourage some people to remove domain_realm
>         mappings.

I don't follow that concern.

Nico
--