[9] in Kerberos
Kerberos and rlogin services
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:12:45 1987
From mtc@ATHENA.MIT.EDU Sat Jun 14 12:36:52 1986
To: saltzer
Cc: kerberos, geer, jis, charlie, noah
Subject: Kerberos and rlogin services
Date: Sat, 14 Jun 86 12:34:52 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
[Reminder: for those of you not already on the new "kerberos" mailing list,
add yourself via madm if you want to participate in these discussions.]
Jerry,
This is a reply to your two notes of Saturday June 14. I have avoided
addressing issues not directly related to the my part of the project
in favor of letting Cliff or Steve comment on them.
> ...for simplicity, the switches [whether to use normal or Kerberos-
> authenticated protocols] probably should consist of placing
> either or both of two demon startups in /etc/inetd.conf.)
That is exactly the case now.
> ...it might be appropriate to make it possible to tie it in to
> opening of an X window, and call it "xlogin" rather than "rlogin".
I've been calling it "klogin" etc. Programs which start with "k" are
just links to their "r*" counterparts; for the daemons (servers), the
name of the program is used to determine the expected protocol. Switching
to "x*" names is okay with me, except that implies some interaction with
the window system. Maybe that's appropriate; we COULD extend rlogin to
pop up a new window for the session if we know we are on an X display.
> a single command named "rlogin" with the current user interface
> might under the covers first try to invoke the xlogin protocol,
> and if rebuffed (by the new, cleanly specified xlogin protocol)
> then attempt to use the rlogin protocol on the old rlogin port.
That's the way it is now, except for the new protocol.
> It certainly seems to me that rsh, rcp, and rlogin should be handled
> as one service and thus use one service key.
I agree. What to call it to distinguish it from other Kerberos clients?
"xlogin" does not seem to be a good name for a service that includes rsh
and rcp.
> ...the idea that Kerberos should be controlled using a mechanism
> like the rlogin /etc/hosts.equiv and ~/.rhosts files is going
> the wrong direction...The notion that Kerberos might be trusted
> but only if the login comes from certain hosts or users is flawed.
I agree that the use of these two files is a mess, non-intuitive, etc,
and that the proposed extensions to the file make it much messier.
Thus, you are proposing to eliminate this kind of administrative
control from Kerberos-authenticated services altogether. That implies
that Kerberos authentication, together with the protection obtained from
the Un*x password and file system, is sufficient control for remote access.
> the old protocol is so badly designed that it can't be extended;
> yet the proposed new protocol is just as bad as the old one...
> Create a new protocol on a new port that is Kerberos-only, that
> has a nice clean protocol specification, and that is tailored to our
> real requirements...a single new protocol (the one I call xlogin)
> should actually suffice to do all of these things.
I have approached the project with the philosophy of changing as little as
possible to get the work done, to avoid side effects of the changes; the
"new" protocol is a simple extension to the old one. A new protocol sounds
like a good idea, and I'm willing to design and implement one.
The major problems with the old protocol are the following:
1. It is not (readily) extensible (in some situations)
2. It provides no feedback (normal/error indication)
3. The only way to determine whether we have the entire message
is context-specific - have enough Null-teminated strings been
received?
Off the top of my head, I can think of a very simple, clean protocol that
addresses these points, while providing the necessary exchanged of
information. I'd appreciate comments from those of you who have more
experience with protocol design. A (very) rough sketch follows:
1. Send first a function code, two or four bytes, which requests an
action and implies the form of the parameters that follow, and
a length attribute to state how many bytes of message follow.
The length is necessary because some messages, like the Kerberos
ticket, will not be Null-terminated strings.
Some initial functions:
a. Kerberos-authenticated rlogin request (followed by ticket and
other information)
b. Kerberos-authenticated rsh/rcp request (followed by ticket and
other information). These are the same function because rcp
uses the rshd server.
c. Acknowledgement, followed by a status code (okay, error code, etc).
2. The server side always sends back an acknowledgement. The client
acknowledges the acknowledgment, signalling the server to actually
do its work.
Note that this protocol provides all of the services we are discussing,
in the same way as the rcmd() routine now provides them.
mtc
