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

From: Ken Hornstein <[email-masked]>
Date: Thu, 09 Dec 1999 15:19:44 -0500

>Well, an implementation that does not depend on DNS security is already in
>fairly wide use -- a 100's of thousands of copies. Soon to be millions.
>
>And it depends on nothing not in the 1510bis draft.

I think I'm confused.  Are you saying that the MS Kerberos implementation
doesn't depend on DNS security, but does _not_ implement the name referrals
draft?  If that is the case, how do you do name resolution in this
implementation?

--Ken
==========================================================================
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: Thu, 9 Dec 1999 11:12:23 -0800

> -----Original Message-----
> From: Jeffrey Altman [mailto:[email-masked]]
> Sent: Thursday, December 09, 1999 10:46 AM
> To: Paul Leach (Exchange)
> Cc: Jonathan Trostle; 'Ken Hornstein'; Derek Atkins; Ken Raeburn;
> [email-masked]; Mike Swift (NT) (Exchange)
> Subject: RE: comments on krb-dns-locate draft
> 
> 
> > > > 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?
> > 
> > Because it found an SRV record for the name 
> "cunix.cc.columbia.edu". Or
> > multiple CNAMEs.
> 
> So if the user decides to telnet to sawasdee.cc.columbia.edu the
> client software is supposed to magicly figure out that sawasdee is
> just one of a cluster called cunix.cc.columbia.edu?

No. There would be two entries for the service's key: one for
"host/sawasdee.cc.columbia.edu/cunix.cc.columbia.edu" and one for
"host/sawasdee.cc.columbia.edu".

> 
> > > How is the service supposed to know to accept it?
> > 
> > Because it is configured to know it is one of a set of replicas.
> 
> There is no mechanism in place for a service to know that it is
> installed on a machine which is part of a cluster sharing a common
> alias.

The only "mechanism" needed is multiple entries in the KDCs database.

  Nor is there any reason why the service should be aware of
> this information.

Sure there is -- so that a client can get assurances from the KDC that it is
talking to an authenticate instance of the service.

> 
> Before providing one line answers it is necessary for you to provide
> the list of assumptions that you are making about the environment
> because it is obvious from the direction that all of these threads
> have taken that there is a huge gap in the assumptions being made
> about the environment.
> 
> In all of my answers I am assuming a heterogeneous environment with
> minimal configuration information available to both the client and the
> services.

Me too.

>  I make no assumptions about which vendor's KDC is being
> used and backwards compatibility is of primary importance.

Me too. Except that backwards compatibility with insecurities is not
required.

> My goal is
> make Kerberos as easy to use as the broken authentication provided by
> SSH.
> 
> Kerberos for its entire existence depends on the DNS infrastructure.

If it's really true that Kerberos has always depended on the
non-spoofability of DNS, then Kerberos has always been broken.

> While I appreciate the desire to close potential attacks it seems
> absurd to me to be spending time on working to avoid an attack that
> will be will closed by the deployment of DNSSEC.  Any protocol change
> will take X number of years to agreed to, implemented and then
> deployed.  How does that time frame compare to the deployment time for
> DNSSEC?  Are they on the same curve?  If so, we should drop this
> discussion entirely.

Paul