What are the issues with dns_lookup_realm ?

[Brian Candler]

On Mon, Oct 04, 2010 at 12:57:17PM -0400, Greg Hudson wrote:
> On Mon, 2010-10-04 at 07:01 -0400, Brian Candler wrote:
> > (1) What DNS lookups are made by the workstation and/or the server when a
> > connection takes place?
> 
> pc.foo.example.com looks up a TXT record for
> _kerberos.server.bar.example.com.

OK, that makes sense. The server doesn't care anything about the hostname/IP
of the client, as the client has already authenticated into a particular
realm.  But the client has to work out which realm the server belongs to,
and to trade tickets as necessary to prove its identity to the server in
another realm.

Which brings me to an aside: does this mean that all communication is
initiated by the client to each KDC, except for the final server to its KDC? 
There's no KDC to KDC traffic?  I'm particularly interested whether I can
make the following scenario work with a NAT/PAT firewall:

                              NAT>
                              +-+
    client  ----------------> | | ----------------> server
                              | |
                              | |
     KDC for                  | |          KDC for
  FOO.EXAMPLE.COM             | |      BAR.EXAMPLE.COM
                              +-+

If the communication goes
  client -> KDC FOO
  client -> KDC BAR
  server -> KDC BAR
then I think it should work. I'll need a more complex testbed to try it out
though :-)

> By spoofing a TXT reply, someone could cause you to use
> host/server.bar.example.com at ATTACKER-REALM service tickets instead of
> the correct tickets.  The attacker will presumably also spoof the IP
> address of the server.  The client then successfully mutually
> authenticates to the wrong host, and perhaps forwards credentials there
> or enters a password, compromising the user's account.
> 
> For this attack to succeed, ATTACKER-REALM needs to be a realm which the
> client can perform cross-realm authentication to.

Many thanks for your clear and detailed explanation.

Regards,

Brian.