bug: krb5_get_host_realm() no longer uses DNS

[Richard Silverman]

On Wed, 19 May 2010, Greg Hudson wrote:

> On Wed, 2010-05-19 at 16:15 -0400, Richard Silverman wrote:
>
>> I don't understand how this will break referrals.
>
> The design of referrals support assumes that referrals from the local
> realm are less reliable than explicit local configuration, and more
> reliable than DNS-based or heuristic mechanisms.

Thanks for the explanation.  My disagreement here is then with the model:
in my system, DNS TXT records *are* "explicit local configuration." I put
them there; I set dns_lookup_realm; I want them used.  In the case of an
acceptor, it's not even used in preference to referrals (since there are
none).  Your later comment about the DNS being spoofable is of course
correct, but each installation has its threat model, and this is not a
concern in mine.  Such tradeoffs need to be left to the sysadmin.

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

> You appear to know your options reasonably well; for what it's worth, I
> would recommend either:
>
> 1. Setting GSSAPIStrictAcceptorCheck false on your servers, and not
> worrying too much about the potential for a client to use the "wrong"
> service to authenticate to sshd.

OK for OpenSSH, but again, there are kerberized services out there that do
not have this flexibility.

> 2. Configuring each server to know what realm it's in (via the default
> realm setting in krb5.conf).

This is bad for user experience: when someone types "kinit" and has no
existing ccache, it's not OK for him to get prompted to authenticate a
non-existent principal in the wrong realm.  The default realm needs to be
the one everyone's user principals are in, not the service realms of the
hosts.

If I wanted to go this route, I would set the host's realm in
[domain_realm] -- but again, this is impractical for me.

Thanks for the suggestions, though.  Any reaction to my suggestion
regarding more fine-grained control over dns_lookup_realm?

- Richard