[186] in Kerberos
"solving" the xhost problem
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:39:24 1987
From swick@ATHENA.MIT.EDU Fri Mar 27 13:50:37 1987
Resent-From: swick@ATHENA.MIT.EDU
Resent-Message-Id: <8703271847.AA10595@HERACLES.MIT.EDU>
To: geer@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU, saltzer@ATHENA.MIT.EDU,
jis@ATHENA.MIT.EDU
Cc: lbm@ATHENA.MIT.EDU
Subject: "solving" the xhost problem
Date: Fri, 27 Mar 87 12:18:04 EST
From: Ralph R. Swick <swick@ATHENA.MIT.EDU>
Resent-To: kerberos@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
----- Begin Forwarded Message -----
After long consideration, it is my conclusion that a real solution to replacing
xhost with a more convenient authorization mechanism will require two additions
to Kerberos. After a lengthy description of the proposed additions, I also
propose a simple short-term solution.
The problem is two-fold; the current authorization based only upon host name
is insufficient in general and should be augmented to authorize by user.
The second part of the problem is, as Jeff points out, a thorny issue in
Kerberos about when a users credentials should be copied to another host.
I propose that the first extension to Kerberos be a request to obtain
temporary credentials (a ticket-granting ticket) valid for a different node
that the one from which the request originates. This should require the user
to re-enter his Kerberos principal key; i.e. the temporary credentials on
the requesting host should never be considered sufficient for obtaining new
ones. As a bone to users less concerned with security, klogin should consult
a table (in the user's home directory?) of nodes for which to obtain
credentials during login.
This solves the problem of having to send passwords in cleartext over the
network in order to kinit on a remote host. I have no definite proposal on
how to get the ticket-granting ticket over to the other node, but the new
rlogin/rlogind work should provide some clues. I do believe that once the tgt
is obtained on the local host, it is acceptable to automatically transfer it
to the destination node when needed. Parenthetically, I believe logout should
always cause a kdestroy.
The second addition to Kerberos is needed to provide a service key for
transient services (i.e. the user's X server). If the service is transient,
it cannot store it's own key in a permanent manner. This is a re-statement
of "workstations cannot have secrets". This proposal requires the addition
of a minimal amount of state to Kerberos, but I believe it will have more
utility than just the 'X0.E40-327-1' service.
Specifically, I propose adding a request, "get service key" to Kerberos. Upon
receipt of this request, Kerberos would create a random service key, store it
in its database and send it back to the requestor. "Get service key" must
require that the service be pre-registered with Kerberos, with an attribute
allowing the generated service key to be stored (by Kerberos; i.e. Kerberos
will need to know that this is a transient service). The transient service
then accepts tickets sealed in this service key for as long as it wants
and can unilaterally invalidate the key (by exiting or requesting a new one,
for example) without having to notify the Kerberos server. "Get service key"
could also require that the service instance include the node name and
that the request originate from the same node. This attaches extra semantics
to the instance, but reduces denial of service interference.
A transient service as defined above inherently cannot be assured the same
level of security as provided to a service that can store it's own secrets.
In particular, it does not protect the transient service against spoofs of the
Kerberos server itself or against wiretapping during transmission of the new
service key.
I believe the above mechanisms are necessary to provide the by-user
authentication desired in X and similar services that cannot keep secrets.
The easy short-term improvement requires only one line to be added to
the user's .cshrc file:
alias xlogin 'xhost \!:1; xterm -n "\!:-1" -e rlogin \!*'
The `xlogin' command has identical syntax to the `rlogin' command but also
causes the remote session to be displayed in an alternate window (a useful
freebie, I believe) and allows any X clients on the remote system to access
the local display.
It may be argued that rlogin itself should be redefined as above and I
believe that would be acceptable.
This does not handle `rsh'd clients, but I suspect that most uses of rsh
are within scripts (like .login) where an explicit xhost is acceptable.
Comments are, of course, invited.
-Ralph
