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

From: Jeffrey Altman <[email-masked]>
Date: Wed, 8 Dec 99 21:53:32 EST

> Assuming that all seven servers are in the same realm, the client doesn't
> care which of the seven it talks to, one solution which fits in well with
> our proposal and results in minimal changes to your code here is to use a
> multi component principal name (mentioned by Paul Leach) of the form:
> host/sawasdee.cc.columbia.edu/cunix.cc.columbia.edu
> The KDC can lookup up this name in the name database and return the correct
> realm. 
> Jonathan

And how is application supposed to know to request that name?

How is the service supposed to know to accept it?

The service verifies the name by performing a reverse DNS lookup on
the incoming IP Address.  This determines which 

   host/hostname@REALM 

key should be used to read the service ticket.

BTW, this functionality completely and utterly breaks on Windows 2000
because Windows 2000 refuses to query the DNS when an application
calls gethostbyaddr() with an address which is assigned to a local
interface.  Instead it always returns a pre-determined string

  HOST.DOMAIN

Not only does this break non-Microsoft Kerberos services but it also
prevents proper verification of hostnames in X.509 certificates
assigned to the host.  

    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: Jonathan Trostle <[email-masked]>
Date: Thu, 09 Dec 1999 10:47:45 -0800

>And how is application supposed to know to request that name?

It does the DNS lookup, finds out that it's an alias. On the reverse
lookup, it picks up the primary name. So it knows how to construct the name.
>How is the service supposed to know to accept it?

Service has to know its own name.

>BTW, this functionality completely and utterly breaks on Windows 2000

Perhaps someone from Microsoft can tell you how to best accomplish the
multiple hosts for a single alias scenario on Windows 2000.

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 09 Dec 1999 14:22:47 -0500

>lookup, it picks up the primary name. So it knows how to construct the name.

Whoah, wait a second .... I thought under krb-referrals, you aren't supposed
to do DNS lookups anymore to construct service names.  Now you're saying
that the client still needs to use DNS?

--Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 09 Dec 1999 12:45:04 -0800

>that the client still needs to use DNS?

Here we are combining the user input with DNS lookup to construct the
service name. Since DNS is involved in name construction, the client could
be redirected (by an attacker) to one of the other 7 servers, but we are
assuming the client doesn't care which of the 7 servers it talks to.

Jonathan

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 09 Dec 1999 16:08:18 -0500

>assuming the client doesn't care which of the 7 servers it talks to.

Okay, I'm trying to understand this here .... does the client always do
a DNS lookup?  What does the client do if it does a DNS lookup and finds
out that the name in question is an alias to a system in another realm?
What if the name typed by the user is a "short" name?  (Not a FQDN)

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 10 Dec 1999 00:44:58 -0500

>assuming the client doesn't care which of the 7 servers it talks to.

Oh, wait, one of my other replies just started me thinking ...

The "primary" name in this example is determined by the IN-ADDR
lookup from the IP address returned from the original name A record,
right?  Isn't that vulernable to being redirected to another host,
possibly in another realm?

--Ken