[1001] in Kerberos_V5_Development
Re: removing user-user authentication from rcp client
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Feb 6 23:40:53 1996
To: "Donald T. Davis" <don@cam.ov.com>
Cc: (Sam Hartman), krbdev@MIT.EDU, swick@x.org
From: hartmans@MIT.EDU (Sam Hartman)
Date: 06 Feb 1996 23:40:42 -0500
In-Reply-To: "Donald T. Davis"'s message of Fri, 02 Feb 1996 20:57:58 -0500
Sorry it has taken me so long to respond to this; I've been
busy getting ready for the start of term and other class-related
activities.
I propose to add an option to rsh, rcp, and rlogin to perform
user-to-user authentication. (For protocol simplicity reasons, both
the daemons and clients would have to know that user-to-user was being
used. Since I don't invision many people running u2u daemons out of
inetd, I don't see this as a real problem. In addition, u2u, by its
nature requires somecommunication between the humans on both sides.
Doing it in other ways without breaking compatability would be
incredibly difficult. ) This would involve a fairly simple change to
kcmd, changes to the command line parsing, and server-side changes.
I would move the code that deals with decoding kcmd requests
all into one place (it's currently using cut-and-paste inheritance,
and is similar enough that this should be done anyway.) Then, I would
add code to deal with u2u authentication. I would also probably want
to make changes so that krlogind at least can be run set-uid root in
order to deal with pty allocation; I invision it running as the user
when it is not trying to get a pty or deal with utmp. I am not sure
how I want to deal with switching to the correct uid--do I allow this,
or require them to log in and get authorized as whoever runs the
daemon.
As far as mutual authentication, I would probably do something
like prompt the user with the name of the principal in the tgt that
was received and ask if this is acceptable. Other options include a
command line flag or enviromnet variable.
I don't see implementing this before the official 1.0 release
with my current schedule, although it shouldn't break compatability or
require API changes, so I'm not sure this is a problem.
--Sam
