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

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 14:34:17 -0800

> -----Original Message-----
> From: Ken Hornstein [mailto:[email-masked]]
> Sent: Friday, December 10, 1999 2:14 PM

> Ah, I was going by Jonathan's example, where he said:
> 
> >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.

I disagree with Johnathan's example.

The client does a DNS lookup, say of "foo.bar.com", and gets back CNAME
"waz.bar.com" which has an A record for (say) 10.0.0.13. It constructs
"host/foo.bar.com" because that's what the user specified (and wants
authentication of) and sets the "name canonicalization" flag. The KDC looks
up "foo.bar.com" in it's krb5.conf file and sees that it is in the "bar.com"
realm, so completes the the name as "host/[email-masked]", and does the
regular TGS processing. When the client gets back the service ticket, it
opens a socket to (say) the telnet port on 10.0.0.13 and does the usual
kerberized telnet thing, including sending the service ticket.

Other than the possible denial of service attack, there was no dependence on
the DNS lookup being correct.

Paul

---

From: Derek Atkins <[email-masked]>
Date: 13 Dec 1999 10:07:08 -0500

Ok, what happens if the client types "foo," which implies DNS lookups
of:
	foo
	foo.dns-search-1
	...
	foo.dns-search-n

Obviously there is no 'host/[email-masked]' which would verify what the
user typed.  The other problem is that the dns-search{1-n} on the
client may not match the dns-search{1-n} on the KDC, so you can't just
pass 'foo' and always get the same implied host.

How do you deal with this situation?

-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: Jonathan Trostle <[email-masked]>
Date: Thu, 16 Dec 1999 14:01:20 -0800

If the order of the search matters, it's because there are multiple foo's.
The client has no way to know which foo the user meant, so this is an
insecurely configured client - neither Kerberos or DNSSEC can solve this
problem. 

Jonathan

---

From: Ken Raeburn <[email-masked]>
Date: 16 Dec 1999 17:52:14 -0500

> insecurely configured client - neither Kerberos or DNSSEC can solve this

I disagree.

Assuming we have a secure way to look up a given hostname, and none of
the domains in question have been compromised, we can securely give
the user what was requested, i.e., "the first foo.<domain> using this
list of domains".  Implicit in the creation of the domain search list
and the use of unqualified hostnames is the assumption of risk that
one of these trusted domains may do something that alters the results.
I don't think that's our problem to solve.
==========================================================================
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: Fri, 17 Dec 1999 17:17:49 -0800

Let me restate it. If there are multiple foo's, the attacker can pick which
foo is selected by the client. So you can't give the user "the first
foo.<domain> using this list of domains". You can only give him some foo in
the list.

Jonathan