[125] in Kerberos

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

Re: Authentication forwarding

jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:31:24 1987

From spook@ATHENA.MIT.EDU  Wed Oct 22 13:09:20 1986
To: kerberos
Subject: Re: Authentication forwarding
In-Reply-To: srz's message of Wed, 22 Oct 86 10:47:11 EDT.
Date: Wed, 22 Oct 86 11:57:21 -0500
From: Ken Raeburn <spook@ATHENA.MIT.EDU>


    But how can a separate command forward tickets between two hosts in
    a secure way?  There needs to be a session key kept between the two
    parties, which is something that rlogin would have to do.  I like the
    idea of being able to manually forward tickets, though;  I would then
    be tempted in writing a "ksu", which is like "su", except it requires
    kerberos tickets, not passwords.  Keeping login passwords off the network
    doesn't help if people have to type in root passwords...

While it could be done for trusted timesharing machines, workstations
(or not-necessarily-trusted timesharing systems) on the receiving end
do not present a reasonable way to do this before logging in.  If the
initial rlogin protocol set up the session key (randomly generated?),
this key could be used later to transfer the TGT (or a limited set of
tickets) after logging in, could it not?

The session key would not in itself provide a way to get the TGT from
the host without the user requesting that it be sent, but if the user
decided he wanted to use the TGT from the remote host, he could then
send it over, via a separate program.  That would still allow someone
to send a phony TGT, but if the program that did the receiving were to
check that a valid rcmd ticket could be requested for that user, given
the supposed TGT that it was given, this could be excluded.

Since the program receiving the TGTs from the network and rlogind
would be running independently, some location in the filesystem would
probably have to be predetermined as the location of that user's
tickets; some sort of double server accepting TGT-transfer connections
from the network and accepting pathnames from local processes (through
a socket accessible only through setuid programs?) would be possible,
but a little messy.

[An even messier possibility -- add to the klogin protocol an escape
sequence that says "here comes a TGT!", and a sequence on the user
side....]

_kr


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