[121] in Kerberos

home help back first fref pref prev next nref lref last post

Re: a different proposal for authori

jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:30:55 1987

From jis@E40-311B-2.MIT.EDU  Tue Oct 21 10:57:55 1986
Date: Tue, 21 Oct 86 10:55:37 EDT
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Clifford Neuman <BCN@WARD.CS.WASHINGTON.EDU>
Cc: Saltzer@ATHENA.MIT.EDU, jg@ATHENA.MIT.EDU, jis@BITSY.MIT.EDU,
        miller%erlang.DEC@DECWRL.DEC.COM, kerberos@ATHENA.MIT.EDU,
        watchmakers@ATHENA.MIT.EDU, developers@ATHENA.MIT.EDU
Subject: Re: a different proposal for authorization, etc.

	Ah, but the trick is you don't need a permanent service key on
a workstation.  Consider: User logs into workstation. A RANDOM service
key is generated for the "X" service and stored into /etc/srvtab. Now
when the user does an rlogin to a timesharing system (assuming that
rlogin hands over tickets), rlogin calls a subroutine (yet to be
written) that constructs an "X" ticket for use on the timesharing
system by fetching the service key out of /etc/srvtab. The timesharing
machine can then use this ticket for creating authenicators that the X
server on the workstation can check using normal kerberos subroutines
(rd_ap_req).

	The beauty of this approach is that it is secure, and requires
NO interaction with the kerberos server. Although the kerberos
PROTOCOL is used, the server is not because there is no need to use a
central registry to hang onto the service key.

	In fact we may want to generalize this one step further by
creating a service name of "ME" (well we can pick a better name, but
I'll use this for an example) which could be used by all services that
run on the workstation. Specifically all services that want to know
"Is this incoming connection being made on behalf of the user which is
using ME."

			-Jeff



home help back first fref pref prev next nref lref last post