[3792] in Kerberos
Re: can someone make KClient handle athena.dialup.mit.edu?
daemon@ATHENA.MIT.EDU (Dan Geer)
Fri Sep 2 17:46:46 1994
To: "Jon A. Rochlis" <jon@cam.ov.com>
Cc: Kerberos Developer List <KRBDEV-L@BROWNVM.BROWN.EDU>, brlewis@MIT.EDU,
tytso@MIT.EDU, kerberos@MIT.EDU
In-Reply-To: Your message of "Thu, 25 Aug 1994 18:09:46 EDT."
<9408252209.AA17647@kung-pao-chi-ding.aktis.com>
Date: Fri, 02 Sep 1994 17:29:51 -0400
From: Dan Geer <geer@cam.ov.com>
For the MIT pool of dialup hosts we have a scheme where named responds
to queries for athena.dialup.mit.edu with whichever host it thinks is
up, allowing logins, and has the least load. So a user who telnets to
athena.dialup.mit.edu will get a banner for, say, alfredo.mit.edu. If
they need to login again later to the same host, (say they want to
retrieve a file from /usr/tmp), they have to specify alfredo.mit.edu
because athena.dialup.mit.edu might resolve to something else.
This scheme breaks Kerberos authentication, because clients will try to
get tickets for rcmd.athena@DIALUP.MIT.EDU rather than
rcmd.alfredo@ATHENA.MIT.EDU.
I work around this in Unix telnet by modifying krb_realmofhost() and
krb_get_phost() to reverse resolve the IP address of
athena.dialup.mit.edu to get the hostname from which to derive the realm
and instance. Ted Ts'o tells me this is good behavior for Kerberos in
general. It ought to go into all versions of Kerberos.
Hi Bruce,
I don't like this very much. You are proposed to rely on the DNS to
provide security information and assumning that you *can* reverse
resolve in the first place. Resolving an IP address isn't a security
issue, since you know the name of the service you're trying to use,
but when the service name can change out frome underneath you, you
could wind up talking to an a fake server and mutual authentication
won't help you. For the same reason, get_phost's cannonicalization
has always bothered me.
I would suggest a better workaround for your problem might be to share
a common key for rcmd.athena@ATHENA.MIT.EDU on the dialup server's
srvtabs and change krb.realms (or the appropriate resource on the Mac)
to equate put hosts in DIALUP.MIT.EDU domain in the ATHENA.MIT.EDU
realm. While I generally hate to see servers share secret keys (ala
AFS), this might be a reasonable exception. On the other hand perhaps
a comprise of the servers with shared keys is more likely than a DNS
attack, but that's a tough call. I just don't like to see this put
into the Kerberos libraries as a general approach.
The circumstances under which shared keys
might be rightly called acceptable are
when the service providers (machines) involved
are identical, co-located, and dataless.
In short, when they simulate a well configured
multi-processor that has no resources of its
own worth thieving.
As always, the evaluation to think/use is that
of containment: would breach of facility X
materially advance the attacker's ability to
make a further breach, either in space or time.
That is why I argue for identicality, co-location,
and datalessness. In short, if they share a
key, they should be indistinguishable and
impoverished.
--dan
