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

From: Jeffrey Altman <[email-masked]>
Date: Sun, 19 Dec 99 3:12:20 EST

> Which DNS query are we talking about? That may be the problem here. I'm
> saying that spoofing the A record lookup for the host name doesn't cause a
> problem; that spoofing CNAMES doesn't cause a problem (because the result
> isn't used in the pricipal name); that looking up the realm in DNS is wrong
> (for the reason you say); and that all uses of inverse IP address lookups
> that I have heard are wrong.
> 
> So, what we have are two cases where using DNS is OK, and two where it
> isn't.
> 
> The way I read Tony's message is that the thing that is being validated by
> the KDC is that the IP address obtained from DNS was good. This is validated
> because only if the IP address is good will the service at that IP address
> be the one that knows the key associated with the principal name supplied by
> the client, said principal name being derived from what the user supplied
> and local configuration information.
> 
> Paul
>  
The problem is that your assumptions about the implementations of
gethostbyname() are wrong.  You are assuming that all implementations
of gethostbyname() return fully qualified domain names.  They do not.

Microsoft Windows 95/98, SunOS, and Solaris are for examples that come
to mind that do not return fully qualified domain names in response to
a gethostbyname("foo") request.

In order to get the fully qualified domain name on these platforms it
is necessary to perform a reverse dns lookup via gethostbyaddr() using
the address returned by the gethostbyname() query.

It is only after the reverse lookup that the client has a fully
qualified domain name with which to determine the realm.  As an
application writer I do not have the luxary of only implementing my
programs on operating system code that is less than a year old.
Please keep backward compatibility in mind when you are making your
suggestions. 

---

But then you still haven't answered the question about the KDC and
where it is going to get trusted data for the realm.  There is not a
KDC in the world other than mine that is going to know that the realm
for 63.71.143.75 is KRB5.COLUMBIA.EDU unless it uses a DNS TXT query
since the domain is used to provide DSL connections to homes and
businesses.  Every single ip address is likely to belong to a separate
REALM.  My ISP (redconnect.net) is very likely to not even be running
a KDC.  So where are you going to get the authoritative response from?

You clearly are not expecting every KDC to keep a local file which
contains the ip address to realm mappings.  So how is this information
supposed to be distributed?

If the KDC is going to rely on DNS, then the next question is trivial.
If I am able to spoof the DNS responses to the client, what makes you
think that I can't spoof the responses to the KDC?

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

==========================================================================
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: Dennis Glatting <[email-masked]>
Date: Sun, 19 Dec 1999 10:56:27 -0800

> Please keep backward compatibility in mind when you are making your

Not to mention a reverse look up is not reliable, or secure. The
reverse zones are woefully incomplete and PTR RRs inconsistent with
As. For example, it is common for find the same A RR for foo.com and
www.foo.com but to which will the PTR point if it exists? Sometimes I
see foo.com, sometimes www.foo.com, and sometimes
someotherhost.foo.com. Which should I believe? What defines an
authoritative FQDN? The PTR or the A?

As a case example I have complete control over a forward zone. I have
no control over the reverse zone, which is operated by an ISP.
Consequently, I cannot assure what will be returned via a reverse look
up or whether it will succeed. In fact, for a two year period a
previous ISP refused to correct a PTR RR error. 

BTW, Solaris, once upon a time, did the reverse look up as a security
thing. Most people disabled it because of the issues I mention in my
first paragraph.