[265] in Kerberos
why knetd?
daemon@TELECOM.MIT.EDU (Jon Rochlis)
Sun Nov 29 17:54:19 1987
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
After reviewing the archives of this list, and thinking about the
upcoming distribution of kerberos, I think it's time to once again ask
the question "why knetd?" Is there a valid reason for its existence
and should we ship it or admit it was ill-conceived and punt while it's
still easy.
Bascially there seem to have been two factors which motivated the
development of knetd:
1) a desire for a "toolkit" layer dealing with the guts of
authentication/authorization so the applications don't have to.
2) conservation of well-known ports
Now, nobody would pretend that #1 has been accomplished. Instead, knetd
currently just accepts connections on the knetd port, reads a bit of
information including the "service" name, forks the appropriate server
(from knetd.conf). No useful authentication/authorization is done
either for client or server! Indeed most servers will need to do
their own authorization in any case.
So all we are left with is an de-multiplexer, which allows us to
succeed in #2, conservation of well-known ports. But I would argue
that two years later (or whatever), that has become a moot point.
Why do you want to control growth of well-known ports? Becuase it's
hard to add new ones? Adding new services is just not difficult. The
majority of people out there will have some Yellow Pages/Hesiod
mechanism for updating information contained in /etc/services, so it
does not requiring updating of thousands of files.
Because you have to register it with the NIC? Better reason, but
people these days hardly seem to care.
And what does using one port cost you? Mainting knetd.conf, knetd,
and *losing* information when using netwatch/netstat! (Is that knetd
connection a telnet, rcp, or pop connect?). The port name scheme for
TCP/IP works fine, and has plenty for room for hundred's of new port
assigments. Do we really need to have a kerberos scheme for naming
network ports?
Somehow I think knetd is a nice idea that just doesn't pan out. I
don't seen the need for the extra complexity of explaining another
daemon, another library, another config file, etc ...
Comments?
-- Jon
