[515] in Kerberos
An idea for forwarding access to remote machines
daemon@TELECOM.MIT.EDU (Mark W. Eichin)
Fri Oct 21 07:35:48 1988
From: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
To: athena-ws@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
I rlogin to multiple machines in my normal work -- the sipb RT server,
my E40 VS2000 (if I am not on it), charon, and occaisional other
machines. Typing my password over the net is obviously wrong (grabbing
passwords typed over the net is more than just a theoretical
possibility) and yet at times I need to authenticate myself from the
remote machine to my file server (and homedirectory) in order to
transfer files (examples: using macsyma or scheme on my VS2000, or
running andrew on the SIPB RT (with 32Meg of swapspace) when I am not
on the apropriate machine type.)
Fortunately, I am a watchmaker, and have root access to priam (my file
server.) Thus I can kinit with my root instance, rlogin to priam as
root, and use `nfsc' by hand to tell priam to create a mapping for me
from whatever remote machine I am using. I have found myself doing
this often enough that I now have an alias for it.
However, I am starting to think that this might be more generally
useful. Providing root access to the server is clearly excessive (that
is: WRONG) but perhaps providing an extension to the nfsid mapping
protocol to allow `proxy mappings', where I present tickets to request
that a mapping from another machine be created.
Note that this is not identically equivalent to the problem of
forwarding tickets to remote machines, as it is not transitive. The
authentication itself is still tied to the machine I am sitting in
front of; I am using this authentication to authorize other machines
to access my files.
One of the classic arguments against `ticket forwarding' is that if I
am away from my terminal for a moment, someone can forward my tickets
to another machine where they can use them to do me harm, without my
being able to revoke that access. If `proxy mappings' are in some way
tied to the authorizing host, then the `flush mappings for this host'
nfsid request can be extended to also `flush mappings authorized by
this host', thus limiting this form of damage somewhat.
Comments? Would this indeed be useful, and which flaws does this
design have that make it impractical?
Mark Eichin
<eichin@athena.mit.edu>
SIPB Member & Project Athena ``Watchmaker''
