[350] in Kerberos
Re: converting a hostname into its realm
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Mon Apr 4 18:56:29 1988
To: Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jon Rochlis <jon@ATHENA.MIT.EDU>'s message of Mon, 4 Apr 88 17:13:37 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> Basically if you use the simple query mechanism any realm you "trust"
> to do inter-realm sytle authentication can spoof any other realm you
> might want to deal with.
Jon's argument is a very good one, but there is a part of it that I
find slightly suspect. If I start things off by saying
rlogin nutmeg.lcs.mit.edu
without specifying which realm I want authentication in, presumably
it is acceptable to connect me with any service that has an
authenticable Kerberos identity of the form {rcmd, nutmeg, *}. If
there is more than one such identity out there, I'm not convinced
that getting a different one from the one I expected is an example of
"spoofing". If I wanted to be connected to the one that is
authenticated by kerberos.lcs.mit.edu, I should have said so. (Not
that we currently have any syntax for saying so.)
Kerberos provides a guarantee that you are talking to the service
that you named, nothing more. If you provide an ambiguous name, then
Kerberos can give only an ambiguous guarantee.
That does mean that we need a way to allow people to specify
unambiguously what service they want, including realm.
> The simplest way to deal with this is to know the hostname to realm
> mapping a priori. A good aproximatation to this is a table in the
> *local* filesystem.
One problem in the Athena environment is that this mapping would have
to be per-user, wouldn't it? I don't think we want to get into the
business of distributing system-wide tables of all the services that
our users may use in other realms--adding a realm becomes a big job.
But a per-user mapping is certainly a nuisance from a user-interface
point of view--each user of the new realm has to add it.
The real problem here appears to be that we want an authenticated
realm default translation but we don't have an authenticated name
service. So the local table is the only way to gain authenticity.
A Kerberos-mediated name server would work as well.
Jerry
