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

From: Derek Atkins <[email-masked]>
Date: 17 Dec 1999 19:32:20 -0500

"Paul Leach (Exchange)" <[email-masked]> writes:

> > -----Original Message-----
> > From: Derek Atkins [mailto:[email-masked]]
> > Sent: Friday, December 17, 1999 7:09 AM
> > 
> > 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).
> 
> No, it will ask for a ticket for "host/foo.bar.com", because that's what it
> knows from what the user specified and from local trustworthy configuration
> data. If a trusted third party, the KDC admin, has put an entry in the KDB
> for "host/foo.bar.com" associating it with a key that the server at 10.2.3.4
> also knows, then the connection will succeed and mutual authentication will
> happen, and everything will be cool. In your example, the bogus server will
> not know the key, the mutual auth will fail and so will the attempted
> exploit.
> 
> Paul

Paul, how can the app do that?  The app has no way to know that
"foo.bar.com" was the 'successful' hostname lookup; it doesn't have
access to the 'resolv.conf' realm search list.  Also, there is
currently no API for an app to determine that information from the DNS
client.  All that 'telnet' gets back is that "foo.tim.org" was the
successful completion for "foo."  What API do you think there is that
can return this information?

Look again at my flow diagram...  The app asks the DNS Client to
resolve "foo", which then goes off and tries each of the domains in
turn.  Finally, it gets a response back (which happens to be spoofed),
and then returns that information to the client.  The DNS client has
no mechanism to return the actual DNS request to the client
application.  So, "telnet" has absolutely no idea that "foo.bar.com"
was the requested hostname.

If you're proposing a new API to enable telnet to obtain the DNS
client domain search path, then I think that by the time this new API
is designed, implemented, and deployed, DNSSec will already be in use.
Moreover, such an API is outside the scope of Kerberos; this is an
application-level problem, not a Kerberos problem.

-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: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 17 Dec 1999 16:14:06 -0800

Paul