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

From: Ken Hornstein <[email-masked]>
Date: Wed, 08 Dec 1999 15:21:31 -0500

>> 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 :-/
>
>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. 

What if the user simply types "name"?

>In the case above, the client should ask for a ticket for
>"host/name.foo.com". The clients wants the KDCs assurance that they are
>talking to the name they uttered.

So I guess the fundamental problem is that naming was always considered
"external" to Kerberos.  Now the proposal we're debating is that this
model should be changed and naming should be placed inside of
Kerberos.  Is this the right thing to do?  I honestly don't know.

>(One can also use trustworty local information to map what the user types
>into the service name.)

mmmmm, hosts.txt.

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

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

Paul