[495] in Kerberos
Re: rcp - a non-trivial problem
daemon@TELECOM.MIT.EDU (Jeffrey I. Schiller)
Mon Sep 5 13:43:12 1988
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: qjb@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: <qjb@ATHENA.MIT.EDU>'s message of Sun, 4 Sep 88 20:06:24 EDT <8809050006.AA16400@M16-034-15.MIT.EDU>
Indeed you have stumbled onto a non-trivial problem. What
makes it non-trivial is that the solution is surrounded by complex
issues that effectively boil down to a tradeoff between security and
convenience (as is usually the case with "security" enforcing
software).
The issue here is how to get tickets on a host which is the
destination of an "rlogin" in a secure manner.
To start some facts:
The tickets in your ticket file are customized to work only
from the IP address they were issued to (it is stored in the ticket)
and are not transferable to another host.
The kerberos server will not (currently) issue tickets for an
IP address (host in other words) given a "ticket granting ticket" from
a different IP address.
The contents of your ticket file is confidential. If shipped
over the network in the clear your kerberos authenticity can be faked
(by those who intercept the network transfer).
Possible Solutions:
Solution 1:
After rlogin'ing in on the destination host. The user manually runs
"kinit" and gets tickets for the destination host.
Advantages:
It works. Already in place (ie. people can do this today, and do no
doubt).
Disadvantages:
Typed password is shipped over the network in the clear (and thus is
interceptable). Inconvenient.
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.
Advantages:
Convenient to use. "Does the right thing" from the (naive) user's point
of view.
Disadvantages:
Requires modification to the kerberos server. 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). I
can now rlogin to host "B" which deposits on host "B" a TGT for you
which is valid from host "B". Now I go and steal the ticket file
(because I control host "B" I can do this) and can now masquerade as
you for upto the ticket lifetime (which is measured in hours). Of
course after I have stolen the tickets I logout of "B" from your
terminal and clear the screen, you are none the wiser that your name
has been compromised.
Solution 3:
Modify rlogin and rlogind (actually klogind) so that as part of the
connection establishment protocol the "kinit" program is invoked on
the destination host to get you tickets. During the invocation of
"kinit" rlogin and rlogind are encrypting the connection so that the
password the user types is not sent in the clear. [There are actually
several ways to implement this that are slightly different then what I
describe above, but are semantically equivalent. The basic idea is
that the user is asked for a password which is securely transmitted to
the destination host for use in fetching tickets.]
Advantages:
Does not require modification to the kerberos server. Securely fetches
tickets on the destination machine (as opposed to solution 1 which
gets tickets in an insecure fashion). Requires that the user provide
his password explicitly so the security hole in solution 2 is not
present.
Disadvantages:
Slightly less convenient then solution 2 as the user has to type
his/her password. Generally unworkable from a shell script (ie. if you
wanted to write a shell script which invoked rlogin on some host and
then fed it commands to execute).
---
If I had my choice of solutions I would go for solution 3
above.
-Jeff
