[188] in Kerberos
re: "solving" the xhost problem
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:39:40 1987
From Saltzer@ATHENA.MIT.EDU Fri Mar 27 16:13:10 1987
Subject: re: "solving" the xhost problem
To: Ralph R. Swick <swick@ATHENA.MIT.EDU>
Cc: geer@ATHENA.MIT.EDU, treese@ATHENA.MIT.EDU, kerberos, jis@ATHENA.MIT.EDU,
lbm@ATHENA.MIT.EDU
In-Reply-To: Ralph R. Swick <swick@ATHENA.MIT.EDU>'s message of Fri, 27 Mar 87 12:18:04 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
Ralph,
I don't think that adding state to Kerberos is the right solution,
but I have an alternative to propose.
To add state is a major change in Kerberos design ground rules, and it
fouls up quite a number of assumptions. For example, the way
Kerberos is currently designed, a Kerberos client goes through a list
of Kerberos slaves that nominally have identical authoritative
information, and uses the first one to respond. If Kerberos begins
to manage state dynamically we have to add some mechanism to get the
word to all the slaves when a user adds a temporary session key at
one of them. For another, if the Kerberos server crashes and reboots,
all authentications EXCEPT these self-authentications still work.
I propose a quite different method. This method would work for X,
and possibly for the other services you were thinking of.
The method is to have the workstation open up a Kerberos service
port, and run a mini-Kerberos service whose only function is to
give out tickets and session keys to clients who present credentials
that originated at this workstation.
I think that the realm mechanism offers enough semantics to pull this
off with no change in any of the current Kerberos machinery. That
is, workstation E40-399-21.ATHENA.MIT.EDU runs a realm with that same
name. The distant host receives the workstation identity, a
ticket-granting ticket, and the session key for the tgt from the
workstation via the undiscussed rlogin/environment-variable
mechanism, and it invokes make-app-request specifying as the realm
the name of the workstation. There is one new subroutine, that adds
the imported ticket to the local ticket collection.
The result is a request back to the workstation, supplying a tgt that
the workstation itself fabricated and can recognize. The workstation
mini-Kerberos responds with an X ticket and a new session key, all
properly sealed up with the tgt session key.
One minor problem this approach has is that without massive tinkering
of the rlogin environment-variable passing mechanism, the tgt session
key would be transmitted to the distant host in cleartext. Fixing
that is only a matter of effort (it and the ticket itself could be
enciphered in the rlogin session key) , which effort may not be
worth it for protecting X windows.
Jerry
