\section{Authentication and Authorization}

%- integrety
%- confidentiality
%- authentication
%- authorization

Many existing networked conferencing systems are explicitly
insecure---they make no guarantees about the integrity,
confidentiality, or authenticity of messages.  They also lack a
flexible authorization system to control access to messages.  Messages
can easily be ``forged'' --- appearing to come from a user who did not
send them --- or sent anonymously.  There is rarely any effective
control over who can enter a message in a conference, or any way to
keep messages private.  {\it Discuss} answers these issues by using an
external authentication system ({\it Kerberos}) in combination with
its own authorization mechanisms.

% \subsection{Private meetings}
%
% Sometimes, a group of people may wish to have a discussion which does
% not become public.  It may be a ``private club'' for a group of
% friends, or a technical discussion between developers of a project, or
%any number of other things.

%	1. Why they are needed
%	2. Project development.  Private groups

\subsection{Authentication}
%	1. Identification problem over network.
%	2. Description.
%	3. Authentic messages.  Guarantee about author.
%	4. Interrealm
%	5. Fallback for local meetings (subprocess stuff).

%- mumble third party encryption based authentication system
%- prove identity using untrusted client software

In an open network system, a network service cannot trust the
integrity of its clients; they can lie about the identity of their
users.  Through the use of an encryption-based third-party
authentication system, such as {\it Kerberos}, it is possible to allow
servers to verify the identities of their clients.  Thus, a {\it
Discuss} server
can use {\it Kerberos} 
to be sure that a supposed author really did originate a given
transaction, and can label the transaction with his
authentication name.

If the meeting is located on the same machine as the client, {\it Discuss}
does not use {\it Kerberos}; instead, it relies entirely on the security
mechanisms inherent in UNIX.  The {\it Discuss} library spawns a
{\tt setuid} back-end program to
handle the requests.  The back-end knows the real user ID of the
front-end, and uses the associated user name as the authenticated
name of
its client.  The mail-to-{\it Discuss} gateway uses this system; mail
messages are entered from {\tt daemon} (the username under which {\tt
sendmail} runs filter processes),  with the original {\tt From:}
line of the mail message appearing in the body of the transaction.

The result of the authentication process, whether through 
{\it Kerberos} or through UNIX mechanisms, is an authenticated name
which is used as the basis for authorization.

\subsection{Authorization}
%	1. Fine-grained access control
%	   i.   Per meeting
%	   ii.  Per user
%	   iii. Different access rights (acdrosw)
%	   iv.  Suitability for use as a `mailbox'.
%	   v.   Problems with negative acls.

Once it has an authenticated name, the {\it Discuss} server must then
make authorization decisions.  One of our early design goals was to
provide fine-grained access controls; that is, it should be possible
to control the access to a meeting down to the accuracy of a single
user.

Each meeting has an access control list (ACL), listing pairs of
authenticated names and the associated access rights they have to the
meeting.  There are seven distinct permissions:
\begin{description}

\item[{\bf a}nswer] allows the user to reply to an existing transaction,

\item[{\bf c}hairman] allows the user to change the access control list.

\item[{\bf d}elete] allows the user to delete any transaction in
a meeting.

\item[{\bf r}ead] allows the user to read any transaction in a
meeting.

\item[{\bf o}wner] allows the user to read, delete, and retrieve
transactions that he entered; usually, chairmen are willing to allow
a user to ``take back'' what he said, but some might not want to allow
that.

\item[{\bf s}tatus] allows the user to find out summary 
infomation (last modified time, number of transactions, etc.) about
the meeting.

\item[{\bf w}rite] allows the user to start a new chain.

\end{description}
It should be noted that no one permission directly implies another.
For example, chairman access does not imply read access.

A user name of ``*'' in an access control list gives the rights for
users who are not explicitly mentioned on the ACL; in addition, a user
name of ``???'' matches unauthenticated users.  A meeting chairman can
prevent anonymous transactions by denying answer or write permission
to unauthenticated users.

% The system does provide for ``negative access''; a user can be
% restricted to having fewer rights than the default.  This can be used
% to try to ``keep out troublemakers'' from a public meeting, but this
% is usually is not successful, since (at least in an academic
% environment) the troublemaker can usually get access to a friend's
% account.

%	2. Server access control.
%	   i.   Creation of meetings.
%	   ii.  No accounting.

In addition to providing control over who can access a meeting, {\it
Discuss} also provides control over creation of meetings;
specifically, an access control list file named {\tt acl} must exist
in the directory in which the meeting is created, and that ACL must
grant `a' access to the user who is attempting to create the meeting.

In the great UNIX tradition, there is currently no quota system
limiting the amount of disk space that an individual meeting can use.
A system administrator may impose a disk quota for the
{\tt discuss} pseudo-user; the total will apply to all meetings.
{\it Discuss} handles disk-full or over-quota conditions 
gracefully.