[269] in Kerberos
Re: why knetd?
daemon@TELECOM.MIT.EDU (Jon Rochlis)
Mon Nov 30 12:18:09 1987
From: Jon Rochlis <jon@ATHENA.MIT.EDU>
To: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: Rochlis <jon@ATHENA.MIT.EDU>, kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Sun, 29 Nov 87 22:33:20 EST,
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.
But that's not what knetd does! All knetd mediates is who gets forked
(ignoring internal services). The only difference between knetd and
inetd is that knetd uses a string passed as the first bytes in the
data stream to name the service and inetd uses the internet port of
the destination address to decide what to fork.
knetd does *not* currently do anything which resembles "securing any
inetd-implemented protocol with having to go inside of its
implementation." You still have to muck with the application, if only
to read off the ticket (the second thing in the data stream) and do
authorization.
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!)
It's a total failure in my opinion. The only vaguely useful things
are (Send Receive)KerberbosData which are only 15 lines long and should
be provided as part of libkrb. All they do is take a file descriptor,
service name, host name (really service instance of course), write (/read) the
service name on the file descriptor, do a mk_ap_req (/rd_ap_req) and
write (/read) the ticket on the file descriptor.
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.
That's what Sun did with portmapper. But it still argues against
multiplexing the use of a single port. My point is no matter how you
do it, you should be able to come up with a port to use to connect to
your kerberos service. It doesn't matter to me whether its through a
nameservice, /etc/services, portmapper or whatever. Knetd doesn't
have to be in between. There are enough naming mechanisms already and
adding one more piece of complexity with dubious functionality is not a good
idea.
I say knetd should be dropped while we still have the chance.
-- Jon
