[347] in Kerberos
re: converting a hostname into its realm
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Mon Apr 4 16:25:48 1988
To: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: John T Kohl <jtkohl@ATHENA.MIT.EDU>'s message of Mon, 4 Apr 88 14:05:58 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> We have a need in the Kerberos system to determine the realm of a host
> given its Internet domain name.
>
> The easiest way to do this would be to have a translation table from
> domain names to Kerberos realms for those hosts whose realm != domain.
>
> An open question is whether the table should be compiled into the
> library function or disk-resident in a configuration file. (The latter
> is much more flexible, but may be prone to spoofing. comments?)
This is a job for a network inquiry, either of a name server or of
the target host itself. The trick is to avoid adding an extra level
of fragility to the system by introducing dependence on yet another
network path and yet another host. A second trick is to keep the
total number of network interchanges from doubling.
I believe that spoofing is not really a problem. By virtue of its
knowledge of the keys of its clients, Kerberos is self-protecting.
The worst thing that can happen when someone slips you a bogus realm
value is that you can't find a Kerberos that can give you a valid
ticket. Since there are lots of ways for me to prevent you from
finding your way to Kerberos or to the service itself, I don't think
that providing info via an unprotected remote inquiry (or by a stored
configuration file) represents a new exposure.
I would be inclined to go at it sequentially:
1. Assume that the target service is in your Kerberos realm and ask
your Kerberos for a ticket. (Your own realm is named in your own
krb.conf.) This will answer 95% of the questions without adding any
packets or delay. [The only thing that could go wrong is if your
realm isn't the right one, but it happens to have a different service
with the identical service name and instance. Since the instance for
a service includes the fully qualified host name, I don't think that
problem arises in practice.]
2. If your Kerberos responds "never heard of that service" then
begin looking harder. Ask the host server itself at a krb-realm
inquiry port. In order to do that, you first have to ask an IP name
server for that server's IP address. Thus in the unusual case of
cross-realm access there is a little extra network traffic.
Question: is there any reason to assume that all the services offered
by a given host are in the same realm? The present krb.conf provides
only a single realm value, but there is no reason why that value
couldn't be indexed by service. Note that the inquiry in part 2 can
include the service name, and therefore the answer can be
per-service.
An alternative to step (2) would be to ask the IP name service for a
record of type krb-realm for the target host. Since you have to be
able to get to that name service to find the IP address anyway, this
doesn't add any extra fragility, but I can't find any particular
advantage to doing it that way, apart from automatic caching of the
result in the name server cache. (I suspect that closely repeated
inquiries for the realm name of the same server are infrequent enough
that caching would have little effect on either performance or
robustness.) And it would be more awkward to provide different
answers for different services at the same host. [We could ask
Hesiod to provide service-dependent realm info, but that would
introduce a dependence on an additional set of servers, and also make
running a Hesiod service a prerequisite for using Kerberos. Both of
those properties are negatives.]
Jerry
