Realm lookups again
Nicolas Williams
Nicolas.Williams at sun.com
Thu Oct 2 11:29:22 EDT 2008
On Thu, Oct 02, 2008 at 11:54:03AM +0200, Mark Phalan wrote:
> On Thu, 2008-10-02 at 02:35 -0400, Greg Hudson wrote:
> > Here is my current thinking on the patch, based on the discussion so far:
> >
> > 1. The default_realm part of the patch is of limited value. It's not a
> > safe default, which means it can't (without compromising security)
> > accomplish the goal of making Kerberos work with zero configuration.
> > Once there is any kind of configuration requirement, people are better
> > off configuring the default realm.
>
> The security problem is that it does a lookup for each interface IP
> address.
> (As already mentioned by Nico) this could be replaced by looking in the
> keytab for host's keytab entries and using the realm found there.
Note that the keytab lookup can't be done at run-time. The process
doing the lookup may not have the permission to do it.
So it has to be done at realm-join time. OpenSolaris has a ralm-join
facility, but MIT krb5 does not.
> Alternatively the local /etc/hosts database could be used to look for
> the interface addresses - actually I understood that libresolv will look
> into /etc/hosts before going to DNS (Nico?).
Getting host info from /etc/hosts is probably not a good idea -- the
names there may not be FQDNed, and reading only from /etc/hosts may be
tricky to do portably.
> > 2. The host->realm part of the patch would let people throw away most of
> > their domain_realm table. So does
> > http://k5wiki.kerberos.org/wiki/Projects/domain_realm_referrals ; I
> > would be interested to know what the status of that project is, and
> > whether people think it would supplant the need for a DNS heuristic or
> > complement it. Or if people think the DNS heuristic is a better idea
> > than domain realm referrals.
>
> I think that both are desireable. The DNS heuristic doesn't require any
> server-side support so will work in more situations. Referrals have
> advantages but do require KDC support.
Right.
Nico
--
More information about the krbdev
mailing list