[92] in Kerberos
Re: knetd
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:25:23 1987
From Saltzer@ATHENA.MIT.EDU Wed Sep 17 23:50:08 1986
Date: Wed, 17 Sep 86 23:31:46 EDT
To: kerberos@athena.MIT.EDU
Subject: Re: knetd
In-Reply-To: <srz@athena.MIT.EDU>'s message of Wed, 17 Sep 86 17:25:20 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Before getting in too deep on knetd, let's review the fundamental
goals of the original ksetup proposal. There were two, both related
to integrating preexisting services with Kerberos as painlessly as
possible:
1. To stop in its tracks the approach of adding a new well-known
port for every old protocol that we adapt to Kerberos.
2. To allow the old protocol to operate without change in its
specification and with a minimum change in its implementation.
The knetd proposal meets goal number 1 beautifully: we add one new
well-known port for knetd and never again raise the issue of defining
more well-known ports.
Goal 2 is not so obviously met by the present knetd proposal. In the
case of UDP protocols, I don't see any way to preserve an old
protocol unchanged and at the same time avoid the extra two packets
for setup.
The suggestion by Stan that knetd should complete the authentication
on the spot and report the authenticated identity of its invoker to
the called subprocess as an extra argument sounds like it advances
the goal of minimizing the impact on old implementations.
And having a separate knetd.conf and inetd.conf is a nice
compatibility win, because a site can decide, for example, to stop
accepting non-kerberos-authenticated rlogins simply by removing
rlogin from inetd.conf. (Assuming that the client strategy for
kerberos-mediated rlogin is to attempt a knetd connection, and if it
is rejected simply invoke the old rlogin command, which will try the
inetd connection.)
Jerry
