[266] in Kerberos
re: why knetd?
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Sun Nov 29 22:37:32 1987
To: Jon Rochlis <jon@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jon Rochlis <jon@ATHENA.MIT.EDU>'s message of Sun, 29 Nov 87 17:37:31 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> 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
Jon,
As I recall, number 1 was not directed at creation of a general
toolkit but rather at the creation of a crutch for preexisting
applications, to minimize the work required to mediate them with
Kerberos. By providing an interface with an inetd-type handoff, the
idea was that you could secure any inetd-implemented protocol without
having to go inside its implementation; just tack on a standard
prefix to the protocol that is stripped off by knetd before the
handoff.
I'd be interested in hearing how successful knetd was in achieving
that goal. If it worked well, maybe the thing to do is simplify it a
bit by using one well-known port per service. That way, knetd could
probably be merged with inetd, leaving a single demon driven from a
single configuration file. (I think that covers all the costs you
listed!)
On the subject of well-known ports, my intuition tells me there is
something not quite right about a requirement to have an entry in
Hesiod, the Yellow Pages, or /etc/services in order to offer a new
service. Somehow it seems it should be possible to offer services
without requirement of a central registry; if I know the name of the
server (which is centrally registered) and the name it knows the
service by, that ought to be sufficient. Central registration of
service names should be possible, but not required. The knetd design
was (perhaps too much) influenced by that consideration.
(Of course lack of central registration does, by definition, make the
life of netwatch harder.)
Jerry
