Question about dns_lookup_realm and domain_realm

[Ken Raeburn]

On Jun 27, 2008, at 11:51, Simo Sorce wrote:
> Thanks, the explanation there makes a lot of sense, but reading  
> through
> the lines it probably would not affect the original poster security,
> because the "insecurity" of the TXT record is exploitable only in  
> case a
> trusted realm is compromised (and the DNS spoofed at the same time).

The "trusted realm" idea gets tossed around a lot, without a lot of  
specifics.  Sometimes what is meant is, "a client in realm A can prove  
its identity to a server in realm B", and with multi-hop cross-realm  
authentication and (someday, we hope) something like PKCROSS, that  
doesn't have to imply any relationship directly between the two.  With  
PKCROSS, all that's needed is KDCs to have certificates issued by  
trusted CAs.  Sometimes what is meant is, "I know the administrators  
of realm B (or run it myself), and I put complete trust in anything  
they tell me, even if they're telling me something about my own users  
or servers". Kerberos cross-realm authentication is about the former.

That said, if you don't exchange cross-realm keys with any outside  
realms, and disable PKCROSS if/when it gets implemented, you could  
have an isolated set of realms collectively considered part of your  
trusted computing base.

>>> How is local configuration data trustworthy given that to resolve  
>>> names
>>> to IPs we still rely on DNS ? Or do you also rely on /etc/hosts  
>>> for most
>>> of the data ?
>> If the host name resolves to a different IP address, the  
>> authentication
>> will fail.
>
> Uhmm perhaps we are thinking of two different things, once you control
> DNS you control both direct and reverse address resolution.

The RFC says a Kerberos implementation shouldn't rely on DNS for  
determining the service principal name.  That MIT's implementation  
does is a bug.  (A long-standing one, one with implications as far as  
choices of names stored in keytabs, and changing it will involve some  
transition issues, as well as needing better support for handling  
multiple names for a server.)  The name you attempt to *authenticate*  
to SHOULD be the name provided by the user, possibly transformed in  
some secure ways (e.g., add the local domain name, but do not look it  
up in DNS without DNSSEC).

Ken