[117] in Kerberos
Re: a different proposal for authori
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:30:29 1987
From jis@BITSY.MIT.EDU Wed Oct 15 00:19:53 1986
Date: Wed, 15 Oct 86 00:18:43 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: Saltzer@ATHENA.MIT.EDU
Cc: jg@athena.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. what a can of worms. One thing I have done often is login
to host A, and then rlogin to host B. Now on host B I want to invoke a
kerberos authenicated service, but I have to get tickets. To get
these tickets I have to give host B my password. Now my rlogin
connection between A and B is NOT enciphered, so my password is going
over the net in the clear, something that kerberos is supposed to
avoid.
What is clearly needed here is for rlogin (kerberos
authenicated version) to transmit a ticket granting ticket for me from
host A to host B using the make_private_message function to hide the
ticket. Now tickets are IP address specific so I cannot merely send my
ticket granting ticket from host A to host B, for that will not work.
I therefore propose that kerberos authenicated rlogin be
changed to perform the following transaction:
Currently the rlogin program (client) makes an authenicator
(with mk_ap_req) for you and sends it with some other information
(terminal type and whatnot) as the first bytes in a rlogin connection.
The server then reads this authenicator and validates it (using
rd_ap_req)
This should be changed so that the rlogin client determines
the IP address you are about to communicate with (it does this anyhow,
how else could it make a connection!). It then using your krbtgt
(ticket granting ticket) it asks the kerberos server for an additional
krbtgt valid from host B. Then it sets up a connection to host B
sending first your authenticator (created with mk_ap_req) and then the
new krbtgt encased in a private message (with mk_private_message)
followed by your terminal type info. The rlogind program (server on
host B), would read this information and then store the krbtgt in
/tmp/tkt_... (ie. where kerberos login stores it now). In this way
your login session on host B will have a krbtgt and be able to go on
from there as if you had logged in directly, and no private
information is sent unenciphered on the network.
Note: You are completely safe, for even if host B is not who you think
he is (ie. someone faked out the name service) your krbtgt will not be
exposed, If B is bogus he won't be able to decode your authenicator
and therefore not get the session key contained therein, which is the
key that mk_private_message used to encipher the transaction that
contains your krbtgt.
Also Note: The kerberos server would have to be modified to support
the "I want a krbtgt for host B" given a krbtgt for host A (of course
this transaction will have to be initiated from host A). Presumably a
library function could be added to the kerberos library to support
this "promotion" of a krbtgt.
Now what does this have to do with X? Well if this mechanism
was in place, then if you rlogin'd to a time sharing system from a
workstation, the time sharing system would have a krbtgt for you and
could get a service ticket for the X server on your workstation and
thus make authenticators.
NOTE: today we DO NOT have service keys on the workstations. If we
wanted the X server on your workstation to accept kerberos
authentication we would have to register an X server instance FOR EACH
WORKSTATION in the kerberos database, and more troublesome, maintain
those keys on the workstations. It is this fact that will probably nix
have the X server use kerberos authenication at all!!!
Enough for one message...
-Jeff
