Subject: I-D ACTION:draft-ietf-cat-krb-dns-locate-02.txt

From: [email-masked]
Date: Wed, 15 Mar 2000 06:21:31 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Working Group of the IETF.

	Title		: Distributing Kerberos KDC and Realm Information with 
                          DNS
	Author(s)	: K. Hornstein, J. Altman
	Filename	: draft-ietf-cat-krb-dns-locate-02.txt
	Pages		: 6
	Date		: 14-Mar-00
	
Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
col [RFC????] describe any mechanism for clients to learn critical
configuration information necessary for proper operation of the pro-
tocol.  Such information includes the location of Kerberos key dis-
tribution centers or a mapping between DNS domains and Kerberos
realms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cat-krb-dns-locate-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-cat-krb-dns-locate-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-cat-krb-dns-locate-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ken Raeburn <[email-masked]>
Date: 15 Mar 2000 14:35:57 -0500

Regarding case sensitivity: The first thing that comes to mind is, "aaahh!!" :-)

The second is, would the administrator of foobar.ibm.com really have
the ability to create entries under "=i=b=m.=c=o=m." for other sites
to see?  I don't think so.  And, as you say, TXT response data is
case-preserving, so it's only in the query that this matters.

I still think the right answer is just to assert that this method
won't work for sites that bend the guidelines so far as to have two
realm names differing only in case and having different servers, and
even then, I can think of at least one way to try to work around it.
The special case of two realm names differing only by case might make
sense if a site is attempting to transition from DCE lower-case mode
to "real" krb5, for example.  But in that case, it might still be
possible for a single server to serve up both realms, though maybe not
with the DCE KDC itself.

Security issues: The second exploit described is an exploit of the MIT
implementation, not the Kerberos design.  The Kerberos model itself
provides no way of determining the realm of a host.  In fact, I don't
think it makes any requirement that multiple services running on a
single host (even without multiple hostnames etc) use the same local
realm.

A random thought: You mention both krb4 and krb5 in the abstract, but
do we have any way of distinguishing a v4-only vs v5-only vs v4+v5
site without having the info stored locally?

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: Ken Hornstein <[email-masked]>
Date: Wed, 15 Mar 2000 16:34:13 -0500

>case-preserving, so it's only in the query that this matters.

Urrrk, good point.

>possible for a single server to serve up both realms, though maybe not

I think Jeff covered that one; I think that we _can_ do either uppercase,
lowercase, or some mixed case if you really want it; the limitation is
that there is room for only _one_ realm in any case within the DNS.

>single host (even without multiple hostnames etc) use the same local

I'm sure we all recall the big flamewar on this, but I can only say
that perhaps it is an "unspecified" area of the specification.  You
certainly have to do something.

>site without having the info stored locally?

No ... and I know we had the big meta-discussion about the amount of
V4 out there versus V5-only sites.  I would agree with Jeff: "Not
necessary" (besides, are people going to do that much reengineering on
V4 clients to make them support this stuff?).

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: 15 Mar 2000 19:19:06 -0500

> that there is room for only _one_ realm in any case within the DNS.

Room for one domain name entry, you mean.

What if I start with:

	myrealm.foobar.com = {
		kdc = dce-1.foobar.com:88
		kdc = dce-2.foobar.com:88
	}
	MYREALM.FOOBAR.COM = {
		kdc = kerberos-1.foobar.com:88
	}

and produce

	$ORIGIN foobar.com.
	_kerberos._udp.myrealm
			IN SRV	0 0 88 dce-1
			IN SRV	0 0 88 dce-2
			IN SRV	0 0 88 kerberos-1

and configure the servers to each handle the "other" realm by throwing
away the packet, so that the client will time out and try another
server?  That last part may be difficult, if the KDC comes without
sources.  But if I can make that happen, it's a workable solution
during a transition period, even if response may be a bit slow on
average.

Yeah, it's bending the rules a little, but once kerberos-revisions
becomes the new spec, the non-upper-case realm will already be in
outright violation of other rules, so bending the rules a little more,
and largely transparently (except that it looks like a server is
down), to make SRV actually work correctly in that bizarre case
doesn't really bother me...

Really, the only situations I can see for two separately-served realms
of the same name are:

(a) v4->v5 transitions

(b) transitioning to upper-case realm name for compliance, a special
case of renaming a realm, which we ought to have a way of addressing
(elsewhere!) anyways

(c) one organization running two realms because, for example, some of
their clients need special authorization data provided by a KDC, and
they're unwilling to be locked into a proprietary solution for the
rest of their environment, *and* they couldn't be bothered to set up a
non-confusing naming scheme for the two realms; just slap 'em upside
the head and make 'em rename one of the realms...

> certainly have to do something.

Yes, it was just nitpicking: The server name canonicalization handling
is not so much a bug in the way the "Kerberos model" works, as
something outside its scope.  (Though perhaps I choose to define that
term more narrowly than some do.)  For example, if you do secure
lookups in your Active Directory for the canonical hostname and reject
anything not listed, that's not at all at odds with the Kerberos
model, and it's probably reasonably secure.  It's "merely" opposite
much of the past experience of UNIX and DNS users (in general, and of
Kerberos), except for those that remember the bad old days of host
tables.

> V4 clients to make them support this stuff?).

It wouldn't be V4 applications, but library implementations like
MIT's, that want to -- or need to -- support v4 compatibility, which
would automatically update applications that shared libraries or get
re-linked.  *IF* we (library maintainers) want to make the
no-config-file situation work, we may need to address this...or at
least decide what our defaults are going to be regarding v4.

If krb-dns-locate isn't intended to address this, the reference to v4
should probably be dropped from the abstract.

Ken