[992] in Kerberos_V5_Development
Re: removing user-user authentication from rcp client
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Fri Feb 2 20:54:53 1996
To: hartmans@MIT.EDU (Sam Hartman)
Cc: don@cam.ov.com, krbdev@MIT.EDU, swick@x.org
In-Reply-To: Your message of "02 Feb 1996 15:59:41 EST."
<tslpwbxjveq.fsf@tertius.mit.edu>
Date: Fri, 02 Feb 1996 20:57:58 -0500
From: "Donald T. Davis" <don@cam.ov.com>
don: i'm hoping that your message isn't about removing "two tgt"
don: support from rcp.
sam: Yes; I'm proposing to remove the two TGT protocol from the rcp
sam: client ... the native encryption support in the krshd is much
sam: preferable to requiring the TGT on both sides of the rcp. ...
sam: no one has been able to figure out why a two-TGT protocol
sam: is preferable for rcp; it's possible we're missing something.
to the rest of the krbdev list:
i've talked to sam on the phone, and we've agreed on
"what is to be done." he's going to summarize WITBD
to this list himself; in this note, i'll give krbdev
the background about u2u, that i gave sam on the phone.
sam paints a picture of how rcp currently works and
how it's used, that has little or nothing to do with
what ralph & i intended in '88, when we designed the
user2user protocol. this is sort of our fault; we left
athena in '91, without leaving behind us any clear
statement about how u2u was supposed to work, except
for the abstract protocol description we wrote in '88
("ws services at project athena" LCS tech memo 424).
we erred in supposing that u2u's proper use was obvious;
the results clearly show that it isn't obvious at all.
we designed u2u primarily for authenticating x service,
but we expected it would be valuable to allow public
workstations to offer other services securely, too.
for example, we wanted people to be able to copy files
from one local disk to another, as when a prof might
send a final exam draft to a grad student, or he
might send a paper to a colleague's machine. nowadays,
of course, people configure private workstations with
srvtabs for precisely this reason, but private srvtabs
were much rarer at mit then, than they are now. ralph
and i explicitly wanted to keep desktop srvtabs rare.
to do this, we wanted to allow kerberos to work in
situations where neither side of the application session
has a srvtab. we knew that without u2u, people would
want to put srvtabs on their workstations, so as to be
able to offer as-yet-unknown services. so, we hoped to
make it unnecessary for people to put srvtabs on machines
that aren't physically secure all of the time. since that
time, we've lost that battle in absentia, in part because
the u2u-capable r-commands we envisioned never got written.
in our defense, though, i'll mention that when we left
athena, the v5 tgs & libraries didn't yet support u2u,
so we had no opportunity to implement the r-commands
of our dreams.
so, that's the background sam asked for. here are my
comments on sam's explanation of why rcp is broken:
sam: The Athena operations people I talked to indicated that requiring
sam: two TGTs was unacceptable. They want to be able to avoid having any
sam: unnecessary root tickets, and want to be able to copy a file from a
sam: more trusted machine to a less trusted machine without getting
sam: credentials on the less trusted machine.
* i'm very surprised to learn that rcp currently demands
a tgt on each end. this is regrettable; i never intended
that any command should use only the 2-tgt protocol.
u2u was supposed to be a fallback, to be used only when
the requested server didn't have a srvtab. so, i agree
that for rcp always to require 2 tgts is broken.
* if it's hard or unreasonable for rcp to automatically
use u2u only when necessary, why not make u2u optional,
rather than removing it altogether? sam and i agree
that something of this sort is WITBD, for all of the
r-commands, uniformly. either make the code try u2u
after krb-ap-req fails, or let the user invoke u2u as
a command-line option.
* i certainly never intended that a single user should
have to get tickets on a remote host in order to run
the u2u protocol; my intent was that two users could
transfer local files, without needing the mediation of an
nfs/afs server. i agree that for any user to have to set
up tickets on each end of a connection is unacceptable.
in fact, i believe that the u2u code should raise a
warning message when it finds that a principal is
authenticating to himself via u2u: "warning - you
probably shouldn't be using this command this way; rtfm."
sam: I fail to see any situations where the two-TGT protocol can be
sam: applied that the rsh encryption protocol cannot be applied to.
now that srvtabs are common on personal machines, you're
right. but athena sacrifices some security by storing such
long-lived secrets on vulnerable machines. kerberos was
designed on the assumption that long-lived secrets always
must sit behind locked doors. note that even if only a few
such srvtab keys get stolen, confidence in kerberos'
effectiveness will be eroded disproportionately. i suggest
that if optional u2u were available for all r-commands
(and perhaps some other services), you could successfully
discourage the widespread use of srvtabs on desktops.
no doubt some users would resist, but any decrease in
vulnerable srvtabs would be good.
-don davis, boston
former athena staff
