Subject: RE: comments on krb-dns-locate draft

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 16 Dec 1999 18:19:00 -0800

> -----Original Message-----
> From: Jeffrey Altman [mailto:[email-masked]]
> Sent: Thursday, December 16, 1999 10:45 AM
> To: Paul Leach (Exchange)
> Cc: 'Derek Atkins'; Paul Leach (Exchange); 'Ken Hornstein'; Jonathan
> Trostle; [email-masked]
> Subject: RE: comments on krb-dns-locate draft
> 
> 
> 
> > > of:
> > > 	foo
> > > 	foo.dns-search-1
> > > 	...
> > > 	foo.dns-search-n
> > > 
> > > Obviously there is no 'host/[email-masked]' which would 
> verify what the
> > > user typed.  The other problem is that the dns-search{1-n} on the
> > > client may not match the dns-search{1-n} on the KDC, so 
> you can't just
> > > pass 'foo' and always get the same implied host.
> > > 
> > > How do you deal with this situation?
> > 
> > The client sends "host/foo.dns-search-n" for the chosen "n".
> > 
> > The choice of names to look up (via the search suffixes) is 
> under the
> > control of the user. Since all they typed is "foo", all 
> they can expect is
> > that the KDC will guarantee that they got a server with 
> "foo" as a prefix.
> > They will get that guarantee, regardless of what DNS returns.
> > 
> > Paul
> 
> So the KDC must be sent N queries?

What made you think that? It gets sent the "host/foo.dns-search-n" for the
_chosen_ "n". I.e., if the DNS lookup that hit was "foo.dns-search-3" then
what gets sent to the KDC in the TGS request is "host/foo.dns-search-3".

Paul

---

From: Derek Atkins <[email-masked]>
Date: 17 Dec 1999 10:08:38 -0500

> what gets sent to the KDC in the TGS request is "host/foo.dns-search-3".

But you can't trust this response from DNS.  Also, as an application,
you have no idea which DNS query was actually successful except by
looking at the DNS response, which you said you cannot trust.  That
means that in ANY case where the user types 'foo', even if there is
only one domain, you are trusting the DNS response (which comes from
the DNS Server, no the DNS Client).

To be more precise:

User            Cl-App          DNS-C           DNS-S
"telnet foo" ---->
                 "foo"----------->
                                 "foo"----------->
                                 "foo.baz.com"--->
                                 "foo.bar.com"--->
                  <---------------<------------"foo.bar.com A 10.1.2.3"

At this point, the Client App gets a DNS response for "foo" saying
that "foo" really means "foo.bar.com" with an IP address of "10.1.2.3".
(In the 'hostent' structure which is returned by 'gethostbyname()').
In any event, you will want to get a ticket for 'host/foo.bar.com'.

Let's say there's a CNAME instead:

User            Cl-App          DNS-C           DNS-S
"telnet foo" ---->
                 "foo"----------->
                                 "foo"----------->
                                 "foo.baz.com"--->
                                 "foo.bar.com"--->
                  <---------------<------------"foo.bar.com CNAME bar.bar.com;
                                                bar.bar.com A 10.1.2.4"

In this case, you 'really' want to get a ticket for 'host/bar.bar.com'
not 'host/foo.bar.com'.  I suppose if bar.bar.com knew all of its
CNAMES, you could have additional tickets for it..

However, what happens if you have a DNS Spoof?

User            Cl-App          DNS-C           DNS-S
"telnet foo" ---->
                 "foo"----------->
                                 "foo"----------->
                                 "foo.baz.com"--->
                                 "foo.bar.com"--->
                  <---------------<------------"foo.tim.org A 10.2.3.4"

At this point, the client will ask for a ticket to "host/foo.tim.org",
because it has to find the FQDN somehow (and the only way is via the
DNS result).

So, now what?  This user is already scrod.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       [email-masked]                        PGP key available
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 17 Dec 1999 17:21:35 -0800

In the previous examples, we established that foo.bar.com has to be part of
the server name. Why isn't it part of your DNS spoof example after you
successfully query the DNS for the CNAME and A RR's?

Jonathan

---

From: Ken Raeburn <[email-masked]>
Date: 17 Dec 1999 22:00:53 -0500

> the DNS Server, no the DNS Client).

Once again, this is with the implicit assumption that we cannot change
the way things work right now.

IMHO there is a high cost to it, especially for anything dealing with
name resolution, where there's lots of existing code and standardized
APIs, but it's doable.  Not necessarily desirable, but doable.

>                   <---------------<------------"foo.bar.com A 10.1.2.3"

Actually, I think the multiple requests are between the application
(really, resolver library) and local nameserver, at least on UNIX with
BIND.

In some implementations it might be necessary to move the loop from
the resolver library up into the application, which IMHO is incredibly
unlikely, but at least with the code on my NetBSD box, h->h_aliases[0]
appears to be the FQDN of the alias (e.g., gnuftp.raeburn.org, where
gnuftp was passed to gethostbyname, and raeburn.org is second in the
search list).  It may be different with different data in the zone.
And unless we get some guarantees about the library's behavior, the
application would still have to open-code it or at least validate the
alias returned.

> CNAMES, you could have additional tickets for it..

As I understand Paul's argument, you'd ask the KDCs for
host/foo.bar.com, because you'd know that that's the one you got an
answer for.  The KDC would also have to give you the bar.bar.com
substitution.

> because it has to find the FQDN somehow (and the only way is via the

No, the client will ask for tickets for foo.bar.com because it knows
that that was the request that got an answer.  And authentication will
fail, and the application will complain at the user.

Still, I disagree with Paul's argument; I thought the domain search
list was an ordered list, and thus the result should be the first
match.  Unauthenticated NXDOMAIN responses should not be able to
redirect the user to the wrong host even if it's in the search list,
if secure lookups in the domains in question are possible.

Ken