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

From: Jeffrey Altman <[email-masked]>
Date: Wed, 8 Dec 99 0:30:25 EST

> these clients. So these clients need their KDC's to support this extension.
> In the longer term, perhaps DNSSEC will be widely deployed. Even then,
> there will always be some Kerberos clients that for whatever reason, don't
> have DNSSEC. These few clients will still need their KDC's to support this
> extension. 

I still don't see where the attack lies.  You are have already
admitted that using DNS for Realm lookups for the local host is
acceptable.

Now in the case of determining the realm for a service.  The situation
here isn't not at all different.  There are two possible scenarios.

(1) The attacker has changed the realm of the service to point to my
    own realm instead of someone elses.  In this case, I make a
    request to my own KDC which if it has been compromised leaves
    little reason for me to worry about the DNS attack.

(2) The attacker has changed the realm of the service to point to a
    different realm.  Now we have two situations:

(a) The other realm has a cross realm relationship with my realm.
    Now in this case I must request a cross-realm ticket from my
    KDC and present it to the service's KDC.  Again, if this trusted
    KDC has become compromised I have more to worry about than
    the DNS attack.

(b) The other realm does not have a cross realm relationship with my
    KDC in which case I must attempt to retrieve a TGT.  In order for
    me to receive a TGT the KDC must know my password.  If the
    attacker knows my password I also have much more to worry about
    than the DNS attack.

Where is this attack via DNS SRV that I am worried about?

    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: Derek Atkins <[email-masked]>
Date: 08 Dec 1999 10:50:43 -0500

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.  Indeed, one could spoof the DNS SRV (or TXT) and A records
such that the client talks to name.bar.com instead of name.foo.com,
and there is no way to detect this attack.

In the hard-coded-file case, for instance, there is no way to spoof
the realm.  So, even in the case of a DNS spoofing attack against the
A record, name.foo.com -> name.bar.com, kerberos would fail as
name.bar.com would not know the key in realm FOO for
host/name.foo.com.

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.

It is quite easy (and technically, legally, and politically possible)
to setup DNSSec within your own domain.  This particular attack is
only a problem between domains that have shared Kerberos keys.  As
cross-realm keys still require manual intervention, if you want to
protect yourself from this attack you should just perform a little
more manual labor.  Clearly, the solution is to cross-certify DNSSec
Zones, and sign DNSSec keys at the same time as you create the
cross-realm Kerberos key.  This would solve two birds with one stone,
helping to populate the DNSSec world, and also prevent this DNS
spoofing attack.

Have a Nice Day. :)

-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: Ken Hornstein <[email-masked]>
Date: Wed, 08 Dec 1999 13:02:44 -0500

>name.bar.com would not know the key in realm FOO for

You're not considering the case when you spoof a CNAME for name.foo.com
pointing to name.bar.com.  You then get a service ticket for
host/name.bar.com.  Same attack, just a slightly different flavor,
and it can be used today without DNS SRV :-/

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: 08 Dec 1999 13:44:00 -0500

> admitted that using DNS for Realm lookups for the local host is

For the local system, we've got the user's key and possibly a host key
to use to essentially validate the DNS info.

>     KDC has become compromised I have more to worry about than

So if KRB5.COLUMBIA.EDU and RAEBURN.ORG exchange cross-realm keys, and
RAEBURN.ORG is compromised, you've suddenly got a big security
problem?  Are you going to refuse to authenticate yourself to anyone
without reviewing their KDC security practices first?  I think there's
a limit to how much "trust" should be implied by merely exchanging
cross-realm keys.

> and there is no way to detect this attack.

If the TXT record is spoofed to refer to a compromised realm and the
attacker can pretend to be the target IP address (whether by messing
with routing tables, or plugging in to the local net while a server is
down, or whatever), the authentication appears to succeed *and* the
address appears to be correct, yet the connection is still
compromised.  So it's possible to do the attack with just a spoofed
TXT record and leave the address alone.

> we need a legal/policiat solution, not another technical solution.

So, what are they?

> helping to populate the DNSSec world, and also prevent this DNS

Makes sense to me...  There's still the issue of excessive manual
configuration, for every domain that uses a realm you can reach
(including indirectly), but at least that should be confined to the
servers.
==========================================================================
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]