[2176] in Kerberos

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

Re: Existing authentication mechanisms have a deficiency

daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Wed Sep 9 00:42:46 1992

Date: Wed, 9 Sep 92 00:26:09 -0400
From: tytso@Athena.MIT.EDU (Theodore Ts'o)
To: nessett@ocfmail.ocf.llnl.gov
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: Danny Nessett's message of Tue, 8 Sep 92 16:03:34 PDT,

   Date: Tue, 8 Sep 92 16:03:34 PDT
   From: nessett@ocfmail.ocf.llnl.gov (Danny Nessett)

   It seems to me, after the discussion about su, ksu, etc., that
   something is missing from existing distributed authentication
   mechanisms.....

   If an organization wants to keep its authentication data in exactly
   one place, existing authentication mechanisms are insufficient. 

Yup.... what's missing is "an authorization mechanism".  Both Kerberos
and SPX purport to offer an "authentication", and completely punt on the
"authorization" issue, leaving that as an exercise for the application
writer to deal with.

While this may seem to be an amazing cop out, since every nearly every
application which uses the authentication services provided by Kerberos
or SPX will require some sort of authorization policy, even if it is as
simple as checking an ACL, file, there is a good reason for this design
choice.  And the reason is this:  

	While authentication systems are relatively well-understood at
	this point, authorization policies are not.  

Specifically, there is no good, general model which shows what sort of
functionality an system would need in order to provide a completely
general authorization policy which would work for all possible
applications.  There have been attempts to do so --- ECMA has issued one
or two technical reports which try to do so --- but they tend to be
fairly confusing, and it is not clear at least to me whether they
generate more light than heat.  So it seems fairly clear to me that a
workable authorization framework is at least partially still an area for
research.  

What we use at MIT Project Athena is a system called "Moira" to handle
our authorization policies.  Specifically, it is a database system which
automtically distributes configuration files to most of the Project
Athena servers every night.  This allows most of the authorizatrion
information to bee kept in exactly one place, as your requirement
specifies.  Since connections to Moira require a Kerberos-authenticated
connection, reasonable access list control can be placed on the Moira
database, and it is even possible to figure out who made what
modifications to a particular database entry.

Moira is big and hard to set up (it runs on top of Ingres), so it may
not be appropriate for all sites.  But it is one solution which keeps a
large part of the authorization information in one centralized place.

							- Ted




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