[206] in Kerberos
Re: handling of tdc?
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:41:54 1987
From jis@BITSY.MIT.EDU Thu Jul 9 14:15:11 1987
Date: Thu, 9 Jul 87 14:13:50 EDT
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: dyer@ATHENA.MIT.EDU
Cc: geer@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU, Saltzer@ATHENA.MIT.EDU,
kerberos@ATHENA.MIT.EDU
In-Reply-To: ---'s message of Wed, 08 Jul 87 15:28:20 EDT <8707081928.AA23441@MENELAUS.MIT.EDU>
Subject: Re: handling of tdc?
We have a problem here, and it is going to get bigger over
time.
Specifically our environment is not really oriented toward
dealing with machines in other domains (or subdomains). Hesiod is only
one example, kerberos is another. The kerberos situation is:
There is an implicit notion in the kerberos software that
one's domain is equal to one's realm (with a special hack that MIT.EDU
maps to ATHENA.MIT.EDU). This comes up in several places. One place is
in answering the question "What realm is that machine over there in?"
which is asked when you need to get tickets for a specific service.
The algorithm is:
Client "C" wants to use "rcmd" service at host "A.FOO.BAR.BAZ".
Strip domain name off of A.FOO.BAR.BAZ yielding FOO.BAR.BAZ as the realm
name and "A" as the service instance. Thus ask for tickets for:
SERVICE=rcmd INSTANCE=a REALM=FOO.BAR.BAZ as the service.
This will not be easy to change. First we need to invent a
mechanism (or use a nameservice like hesiod) to translate machine name
into realm name to use. Second we need to change our current notion of
instance name to be a fully qualified domain name, instead of just the
host name portion.
*
As for the first problem I recommend creating a simple UDP based server
that would run on each machine that would simply return the
machines realm name. Thus to talk to A.FOO.BAR.BAZ you would ask him!
Suppose he answers ATHENA.MIT.EDU, using this information and change
number two above we would get a request for:
SERVICE=rcmd INSTANCE=a.foo.bar.baz REALM=ATHENA.MIT.EDU as the service.
Solving problem number two above is harder. It involves a
massive flagday (the day we convert all the "a"s to "a.mit.edu"s) or
carrying two entries for each service (one with the old instance name
and one with the new) whose keys are the same (this would be a royal
pain in the you-know-what).
Now for the practical short term solution. Stop giving out
subdomain based names to living groups. Note: They are NOT
authoritative for their own domains today anyway (ie. we need to
update tables on campus when they add machines, they don't manage the
domain from the living group). It would therefore be no additional
work on our part to NOT have subdomains out there. We did it
originally because it was "cute" not because of any technical or
procedural reason.
This is a cop-out solution. We do need to solve the above
mentioned problems. However I do not think that the living groups are
the right places to debug it!
-Jeff
-----------------------------------------------------------------
(*) I am disinclined from making the kerberos software dependent on
the functioning of hesiod. A simple UDP based server would have the
property of always being available as long as the service machine itself
was. And if the service machine is unavailable, so what, you cannot
talk to it anyway.
