[101] in Kerberos

home help back first fref pref prev next nref lref last post

Re: knetd

jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:28:24 1987

From jis@BITSY.MIT.EDU  Sun Sep 21 19:37:28 1986
Date: Sun, 21 Sep 86 19:36:40 EDT
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To: kerberos@athena.mit.edu
Subject: Re: knetd

	I think it is pointless to build a table for known
authenicated connections consider:

	Since we first started talking about this proposal, we have
haired it up quite considerably, what that table would have to look
like, and how it would have to be read (ie. you cannot trust the
table, so you have to make sure it is still root-only writable). Well
it is pretty obvious if you go with this approach that you will have
to provide a subroutine call that does all this work for you... BUT WE
ALREADY HAVE ONE it is called RD_AP_REQ. If you have to edit a server
program at all (ie. to add the subroutine call that fetches the
authenication from a table) then you might as well add the call to
RD_AP_REQ.

	There is also another piece of information that rd_ap_req
gives you that hasn't been mentioned yet, that is the session key that
is associated with a ticket, and is provided by the authenicator. You
obviously don't want to leave this key in a readable place!

	What is the objection to using rd_ap_req? It is really the
only subroutine that has to be used by a service (there is an issue of
security having to do with non-trusted services all having to be able
to read /etc/srvtab, but that can be corrected by spliting /etc/srvtab
up into several separate files....).

			-Jeff


home help back first fref pref prev next nref lref last post