[88] in Kerberos
knetd (formerly Ksetup)
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:24:45 1987
From jtkohl@ATHENA.MIT.EDU Tue Sep 16 10:52:26 1986
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Date: Tue, 16 Sep 86 10:45:30 EDT
To: kerberos
Subject: knetd (formerly Ksetup)
Us-Snail: Room A303, 4 Ames St, Cambridge, MA
Zip-Code: 02142-1306
Dan Geer has asked me to work on the proposed Ksetup daemon (which I
would like to rename knetd, for reasons below) and circulate a brief
design spec for it.
The design Jerry proposed has an extra overhead of two messages per
connection, since the client would talk to a kerberos server and then to
the desired server.
I propose eliminating the extra message pair by the following scheme:
knetd, similar in fashion to inetd, will act as a "multiplexor" to the
various kerberos authenticated services.
It will listen to one well-known port for tcp and udp connections. When
a client wishes to connect to an authenticated server, it connects first
to the knetd. The first message is the name (in suitable form) of the
service the client wishes to use.
The knetd correlates this name with a table (of the form maintained by
/etc/inetd) and forks off the appropriate server, with appropriate
arguments such that it realizes it is connected to a kerberos-speaking
client. The server takes whatever authentication and/or authorization
steps it deems necessary. (There are already routines in use by the
login and rcmd protocols which do the grunge work of verifying the
authenticity of a client, so development of the is_this_one_ok()
authorization routine would not be necessary). This has the added
benefit that the existing kerberos servers need not be changed
drastically to accomodate this scenario (they might need a few minor
changes regarding releasing the socket back to the knetd). We would
already need to modify the server's code to allow kerberos
authentication under the Ksetup scenario, so we are not losing ease of
conversion by using knetd. We can also avoid allocating more well-known
ports for new services (if desired) by having them connect through knetd.
This table can be maintained simultaneously with /etc/srvtab and
/etc/inetd.conf.
To cover the problem of people who should use kerberos who are trying to
avoid it by using the old existing protocols, an address filter (similar
to the one used by the userinfod) can be devised to insure they are not
circumventing authentication.
Comments?
