[7271] in Kerberos
Re: Kerberized RCP
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Tue May 14 10:35:15 1996
To: Jeff Dietz <jdietz@baynetworks.com>
Cc: kerberos@MIT.EDU, don@cam.ov.com, swick@x.org
In-Reply-To: Your message of "Mon, 13 May 1996 15:38:03 EDT."
<31978F9B.167EB0E7@baynetworks.com>
Date: Tue, 14 May 1996 10:27:29 -0400
From: "Donald T. Davis" <don@cam.ov.com>
jeff dietz wrote:
> If I have two workstations, Fred and Barney, and I am logged into Fred
> and wish to use (kerberized) rcp to copy a file from Barney to Fred,
> does Barney end up sending a message to the ticket-granting service for
> a new session key, the session being the act of writing from Barney to
> Fred's file system?
you're describing a use of the "user-to-user" protocol.
as ralph swick and i designed the u2u protocol, it's fred,
not barney, who would request the session-key. i believe
a future beta release will have "r" commands that work
in this way, as we intended:
F ---> B: "your tgt, please"
B ---> F: tgt_b
F -> TGS: tgt_b, tgt_f, "rcmd tkt, please"
TGS -> F: {K_b,f}K_tgs,f , tkt_b,f
F ---> B: {authentr}K_b,f , tkt_b,f
B ---> F: {authentr'}K_b,f
so you see, only fred has to talk directly to the tgs.
note that barney loses no security by giving his tgt to
fred, because fred doesn't know barney's tgs session-key.
note also that this allows fred and barney to swap files
without either one having a service's key-table. thus,
even if barney is not physically secure, he can offer a
secure rcmd-service.
ralph and i intended that u2u would be an optional security
mode for desktop-services, and that centralized rcmd servers
would usually use the usual krb_ap_req protocol instead.
it's my understanding that the current kerberization of
the r-commands doesn't yet work quite like this. it seems
that the kerberized rcmds use only u2u, so the remote host
has to have a tgt; they don't yet work correctly if the
remote host has a srvtab instead. this flaw has marginalized
the r-commands, and kerberos sites have moved towards desktop
nfs service as a result. here's why this happened: when
ralph and i left athena, we failed to describe completely
our intentions for u2u, so when u2u was added to the "r"
commands, the implementation didn't have much to do with
our (undocumented) design goals. again, this was my fault,
not the implementors'.
as i'm sure someone on the list will mention, it's uncommon
nowadays for users to move files with rcp; instead, users
routinely configure their desktops as nfs file-servers,
complete with long-lived service-keys. nevertheless, the
user-2-user protocol is more secure for _desktop_ application
servers, because it doesn't expose a long-lived service-key
to theft. this exposure is why ralph and i originally
designed the u2u protocol. u2u is particularly necessary
for secure x-windows, since x-servers almost always run
on physically-insecure desktop machines.
i doubt that the next beta release will include the repaired
r-commands; the developers are very busy right now. perhaps
sam or ted will mention whether some future beta release will
include them.
-don davis, boston
