[497] in Kerberos
Re: rcp - a non-trivial problem
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Mon Sep 5 16:34:04 1988
To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Cc: qjb@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>'s message of Mon, 5 Sep 88 13:38:56 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> . . .
> Solution 2:
>
> Modify kerberos server so that given a TGT (ticket granting ticket)
> from one host, a TGT for another host can be fetched. Use this feature
> to have the rlogin program fetch a TGT for the destination host and
> ship it over (encrypted in the session key that "rlogin" and "rlogind"
> have in common). Possibly do this only if an option appears on the
> command line.
> . . .
> Disadvantages:
>
> . . .
> Is a marginal security hole. Suppose for example I control host
> "B" and I walk up to your terminal which is logged into host "A"
> (assuming you are elsewhere).
There is another plausible-sounding security attack if this solution
is used. Suppose I rlogin to another workstation or a time-sharing
system controlled by C, without realizing that C is not trustworthy.
Solution 2 obtains a fully valid ticket-granting ticket and stores it
on C's machine for the duration of my activity. Even if I destroy
that ticket on logout, there is plenty of time for C to have made a
copy of my TGT while I was logged in, which C can then continue to
use at leisure for all manner of services after I leave.
A similar scenario plagues the other solutions, too. One way to
reduce the exposure would be obtain only an ordinary ticket, rather
than a ticket-granting ticket, at the target machine.
On that basis, here is a solution 4 (only for the specific example of
rcp from C to D from A:
After obtaining the network address, but before opening a connection
to the rlogin server at C, use the TGT stored at A to obtain an rcmd
ticket for D, but specified to contain the network address of C.
(Kerberos change required to support this.) A opens an encrypted
connection to C and sends the rcmd ticket across the connection, then
asks C to perform the rcp to D. At logout, destroy the ticket.
Advantages:
The exposure at C is limited to the ability to do rcmd's to D under
A's identity for the duration of the ticket lifetime.
Disadvantages:
Not awfully general--originator at A has to know at outset what
ticket will be needed to accomplish the job at C. Every different
scenario is another case.
Two more comments:
1. None of these solutions generalize in an obvious way to multiple
levels.
2. For rcp/rcmd, it would seem appropriate to request (as default)
especially short-lived tickets, like ten minutes. The option of
using long-lived tickets should require asking for them explicitly so
the user has a chance to evaluate the exposure on long-running jobs.
Jerry
