Path: utzoo!attcan!uunet!lll-winken!ncis.tis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!agate!shelby!NSFNET-RELAY.AC.UK!jhs%computer-lab.cambridge.ac.uk
From: jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK (Jerome H Saltzer)
Newsgroups: comp.protocols.kerberos
Subject: authentication in news reading
Message-ID: <8905101023.AA04894@uk.ac.cam.cl.dovey>
Date: 10 May 89 10:23:51 GMT
References: <8905091329.AA11693@cs.columbia.edu>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 55

> I've been thinking about this for a while, and it seems to me that a
> Kerberized version of some new protocol (perhaps implemented in RPC
> rather than an SMTP-like interface, so that a dummy server could be
> built that would link directly into the client code to provide "local"
> newsreading without changing anything but a Makefile) at first sounds
> like the way to go, but administering a large list of who gets
> permission to do what is likely to be a major headache.

> For instance, you have class groups (cs160, for example) at Berkeley.
> There would be a list of who gets to read it, who gets to post to it,
> etc.  It has to be kept on the kerberos server and needs to be
> updatable rather easily by a large number of people (TA's, professors,
> etc.).

The mechanism you are looking for is an authorization system, probably
in the form of a set of nested access control lists.  But it probably
should NOT be kept on the Kerberos server.

When we worked out the design of Kerberos we debated whether or not to
include an authorization system, and (after a fair amount of argument)
decided not to.  There are two fundamental reasons:

     1.  The dynamics of authorization cover a much greater range than
     those of authentication--there can be any number of access-control
     lists, they can be of arbitrary and unpredictable size, and they
     need to be be administered by a wide range of people.  Compared with
     the small, slowly-changing, predictably-sized, and
     uniformly-administered database required for authentication, many
     of the design considerations were different, so it appeared more
     appropriate to separate the services.     

     2.  There are many possible models for controlling authorization, and
     different network services may require (or prefer) different
     models.  Rather than trying to choose the one best model, or try
     to implement a general system that caters to all possible models,
     it seemed better to leave the model up to the service.

The way I would approach the business of controlling authorization for
news would be to think through what control features are wanted, and
then build up a news-specific mechanism, based on the assumption that
it can rely on clients to present Kerberos-derived principal
identifiers that are certifiably correct.

> Does anyone have any experience with allowing an update facility to
> large numbers of "somewhat trustworthy" people on large numbers of
> access lists?

Not exactly, but moderately close.  There is a mail list, group list,
and access list update mechanism in the Athena Service Management
System (Moira).  The lists have access control lists of their own and
there is a Kerberos-mediated network protocol for remote update of
lists.  One could probably adapt this system to drive an access
control system for the news system.

						Jerry Saltzer