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

From: Derek Atkins <[email-masked]>
Date: 08 Dec 1999 14:01:05 -0500

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

> > Hi,
> > 
> > From earlier messages, they are worried about instance 2a.  The issue
> > is that if there exists a realm FOO with a shared key with realm BAR,
> > and there exists a service "host/name.foo.com" in both realm FOO and
> > BAR, then it is possible to spoof a client to use realm BAR instead of
> > realm FOO.
> 
> Isn't that plain out-and-out misconfiguration? All keys should be different.

Perhaps this is "misconfiguration."  OTOH, this is the only attack
that is viable by spoofing DNS.  Yes, this is the one and only problem
that people are worried (complaining?) about.

So, no, this really isn't misconfiguration.  It is realm BAR being
mischeivous and actively trying to abuse the trust relationship
between them and realm FOO.  The attack requires the abuse of
cross-realm trust, inserting a key specifically to use with a DNS
spoofing attack.  IMHO, this is not a major concern -- as soon as you
notice that realm BAR is trying to spoof your users, you disable their
key.  Problem solved. ;)

Obviously, if Kerberos ever starts deploying transitive trust paths,
then this issue might rear its head again.  OTOH, I believe that DNSSec
will be in useful deployment by then.

> > IMHO, I think DNSSec is the right solution.  The problems with DNSSec
> > deployment have been legal and political, not technical.  As a result,
> > we need a legal/policiat solution, not another technical solution.
> 
> Since it is feasible to not trust DNS, it is better to not trust it. Since
> you have to trust the KDC, and that's all you have to trust, it seems like
> the clearly superior approach.
> 
> Paul

I disbelieve that it is feasible to not trust DNS.  DNS is already in
the path, converting hostnames to IP addresses.  I agree that trusting
DNS for the TXT record opens up an attack, but by definition the
attack is opened to people you already trust!  It only works if you
already have a shared key.

Also, when DNSSec is deployed, this attack WILL go away.

So, the question is: why do you want to create another service that
duplicates the problem space of DNSSec when DNSSec already exists?
What do you think that you can do better than DNSSec?  Don't forget
the fact that at least the DNSSec code exists and _IS_ deployed in a
small segment of the 'net (even if it isn't actively being used).

-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: Wed, 8 Dec 1999 10:00:14 -0800

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Wednesday, December 08, 1999 7:51 AM
> To: [email-masked]
> Cc: Jonathan Trostle; Ken Raeburn; Paul Leach (Exchange);
> [email-masked]; Mike Swift (NT) (Exchange)
> Subject: Re: comments on krb-dns-locate draft
> 
> 
> Hi,
> 

<snip>

Paul

---

From: Ken Raeburn <[email-masked]>
Date: 09 Dec 1999 00:31:40 -0500

> that people are worried (complaining?) about.

Misconfiguration, attack, po-tay-toh, po-tah-toh.

There are several variants on the DNS attack.

Some, using fake CNAME records, do not require new keys in the
compromised (or merely unfriendly) realm.

One, as I pointed out in a previous message, may not even require
interfering with the address lookup, just the realm mapping, if you've
already got access to the packets.  (I don't consider that a "new"
attack, because the address lookup vulnerability is already present in
that exchange, and if you've turned off DNS A lookups for "security
reasons", the TXT lookups should be turned off at the same time.

Simply redirecting the user's "rsh" command to the wrong host within
the same realm can be damaging, even if the realm and host aren't
compromised.  (Consider "rsh my-old-machine rm -rf Mail" being
redirected to my-new-machine, after a user has copied the home
directory over and read a few days' worth of mail.)

>   IMHO, this is not a major concern -- as soon as you

Except for the new administrator account the attacker added after
cracking one of the existing administrator accounts...

Jeffrey Altman <[email-masked]> writes:
[quoting Paul here, I think]
> > This is a slight oversimplification, but if one wants service
> > authentication, then what needs to be authenticated is "what the user types"
> > (or picks via a UI), not something looked up in an insecure database. 

Using an insecure database is bad.  But so is requiring the user to
type the canonical FQDN all the time, especially considering
service-oriented and convenience aliases.

If my default domain raeburn.org has a CNAME record
cygftp->ftp.cygnus.com, should that ftp server have to have a
"ftp/[email-masked]" key in order for me to access it
using that alias?

> Except that this is not how it works.  If I say that I want to 

This isn't how it works *currently*.  It could be changed.  Not
trivially, and not without reviewing the implications, but it could be
changed.

---

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

(Note: I trimmed the cc: line because I believe all of the respondants
are already on ietf-cat)

>trivially, and not without reviewing the implications, but it could be

I think this is the key point here.

I believe what bothers me most about the approach in the referrals I-D
is that it has many implications, not all of which I believe have been
completely studied and understood.

This is obviously a complex subject, with a lot of differing viewpoints.
Maybe we could benefit a lot by a discussion at the next IETF?  Not
that I'm suggesting _not_ discussing it on the mailing list, but
I think that we'll be able to reach a consensus on the right thing
to do if we could all sit down and interact in real time (I don't know
about everyone else, but _I_ sure have been having a hard time keeping
track of all of the threads here).

--Ken