[2287] in Kerberos_V5_Development
Re: ["Tony Mione" ] DNS lookups for Host Realm information
daemon@ATHENA.MIT.EDU (Christopher Blizzard)
Fri Mar 7 11:45:30 1997
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "07 Mar 1997 11:16:48 EST."
<tsliv33zngv.fsf@luminous.MIT.EDU>
Date: Fri, 07 Mar 1997 11:42:04 -0500
From: Christopher Blizzard <blizzard@appliedtheory.com>
In message <tsliv33zngv.fsf@luminous.MIT.EDU>, Sam Hartman writes:
:------- Start of forwarded message -------
:From: "Tony Mione" <mione@boeing.rutgers.edu>
:Message-Id: <9703061027.ZM589@boeing.rutgers.edu>
:Date: Thu, 6 Mar 1997 10:27:33 -0500
:To: kerberos@MIT.EDU
:Subject: DNS lookups for Host Realm information
:Cc: mione@hardees.Rutgers.EDU
:
:
: We are looking into upgrading to Kerberos v5 1.0 (from Kerberos 5
:Beta 2!). There are a few local modifications that Rutgers has used through
:the years. We are trying to bring up the new kerberos with as few changes
:as possible. Here's the question. One local feature we rely on is called
:the 'DNS hack'. We leave out the realm (we use a '+' in the config file)
:and the library queries DNS. Each host's DNS entry contains information on
:which realm the host is in. This helps us distribute a unified
:configuration file since the realm does not need to be specified there. It
:also helps with authenticating in other realms for services provided there.
:
: My question is, if we reimplemented that change in version 1.0,
:would mit kerberos team be willing to taking the change and incorporate it
:into the next release of Kerberos? The actual code is not very large (1-2
:dozen lines). I am asking since it may not be worth it to try to put this
:code in and support it for each new release. So I would like to have some
:idea if it is worth the effort.
:
Has there been any work at all on a standard method for using DNS as way
of distributing kerberos realm and server information? This would be the
most obvious way of distributing this kind of information and it fits
pretty well into the DNS model. Just adding new records types ( ie: KS
and KR ) wouldn't be too tough. Ok, ok, I know it's not *that* simple. :)
The only problem that I can see is that using DNS as the method for
transporting this kind of information opens end users up to all kinds of
man in the middle attacks.
Anyone have any thoughts on this?
--Chris
------------
Christopher Blizzard
AppliedTheory Communications, Inc.
blizzard@appliedtheory.com
------------