\chapter{Essential Concepts}
\label{chap:concepts}

The basic function of a Nox server is to encrypt and decrypt messages in
a key which is known only by the server.  To do this, it maintains
``encryption compartments,'' which consist of keys which are used for
encrypting and decrypting user data and some access control information.

When a Nox client wishes to encrypt or decrypt data, it first opens a
connection to the Nox server, and authenticates itself to 
Nox using an external authentication system, such as
Kerberos\cite{Kerberos}.  During this process, it obtains a session key
to use for the connection.  All data sent between the Nox
server and client are sealed in this session key, in order to prevent 
eavesdroppers on the network from obtaining any transactions between the 
Nox client and server.  

To encrypt data, the Nox client sends to the Nox 
server the name of the encryption compartment which it wishes to use
along with the data to be encrypted.  If the user is authorized to
encrypt data using the specified compartment, Nox will encrypt the data 
(along with timestamp and signature information) send it back in a {\em
satchel}.  The client is then free to store or transmit the satchel in
whatever manner it sees fit.  Figure~\ref{noxprot} shows an example of
the above exchange.

\begin{figure}
\begin{center}
\PSbox{nox-prot.ps}{5.15in}{2.33in}
\end{center}
\caption{A simple transaction involving the Nox server}
\label{noxprot}
\end{figure}

To recover the data which was stored in the satchel, the client must
again authenticate itself to Nox and obtain a session key to use for the 
connection.  It can then send the satchel to Nox and if the
user is authorized to decrypt the satchel, then Nox will send the data
back to the client, along with various status information such as who
created the satchel and when.  (Note that all data sent between the Nox
client and the Nox server is encrypted in the session key; for this
reason, eavesdroppers will not be able to intercept the data as it is
sent from the Nox server to the client.)

\section{The Encryption Compartment}

The {\em encryption compartment} is the basic security abstraction in
Nox.  It takes its name from compartments which are used by the
Intelligence community for controlling who is allowed to access highly
classified materials.  Users who need to know information related to a
particular operation are placed into a compartment.  The virtue of
compartments is that it is a formalized way of controlling who has
access to a particular class of sensitive information.  Like its
namesake from the intelligence community, Nox compartments are used to
organize information on the basis of who should be allowed to access
particular classes of information.

The following information is kept in an encryption compartment:

\begin{itemize}
\item A list of encryption keys

\item A textual description of the compartment

\item A sequencing id

\item Access control information
\end{itemize}

Each entry in the list of encryption keys is stored as a triple: $<$key
version number, encryption system, key$>$.  When the Nox server creates
a satchel under the control of a compartment, it uses the key (and the 
specified encryption system) with the highest version number to encrypt
the data.  Since satchels do not get updated when a new key is generated
for their compartment, all previous keys must be kept by the Nox server.
When a Nox server needs to decrypt a satchel, it uses the key version
number stored in the satchel to determine which key to use.

The compartment description contains human-readable text describing the
purpose of the compartment and is intended for use by the Nox
administrators.  Since the description of the compartment 
may not be public, access to it is protected by the Status
access right (see below for a description of the access control system
used by Nox).

If sequencing is enabled, the sequence id stored with a compartment
contains the next sequence id to be assigned to a satchel encrypted
under the control of that compartment.  This allows satchels to be
strongly sequenced in order of their creation, which is useful in
some applications.  (See chapter~\ref{chap:applications}.)

The access control information which is stored in a compartment is a
generalization of access control lists.  Nox's generalized access
control lists are used to determine whether or not the server should
honor an authenticated principal's request.  Principals' privileges are
divided into various access rights, which can be selectively enabled or
disabled for each principal.  For compartments, Nox supports the
following access rights:

\begin{itemize}
\item Administrate --- this allows the user to add, delete, and modify
entries on the compartment's ACL.

\item Encrypt --- this allows the user to seal messages in the compartment.

\item Examine --- given an satchel encrypted using this
compartment, this allows the user to obtain the name of the compartment
and the accompanying status information.  time stamp, optional ACL, etc.)

\item Decrypt --- given an satchel encrypted using this
compartment, this allows the user to unseal the message.
(The user must also either know the name of the compartment or have
Examine access.)

\item New Key --- this allows the user to request that a new key be
generated for this compartment.  Older keys are kept so that
packets encrypted using them can still be decrypted.

\item Status --- this allows the user to list the members of the ACL and
to display the last time the compartment was changed and by whom.

\item Build-in ACL --- this allows the user to encrypt a message with a
satchel-specific ACL embedded within it.
\end{itemize}



\section{Access Control and Proxies}
\label{genACL}

Nox's generalization of access control lists allows a compartment to be
configured so that several users must act in concert to perform an
operation.  In addition, Nox's access control mechanism allow a user to
perform an operation on behalf of another (authorized) user.  Both of
these features are provided by  {\em proxies}.

Each compartment contains an access control list which associates users
with the access rights they are allowed to exercise in that compartment.
However, instead of each user either having or not having a particular
access right, as is done in traditional ACL systems, each user is
assigned an integral number of ``votes'' for each access right.  The
administrator of the compartment sets the threshold number of votes
that must be presented for each access right in order to exercise that
access right.

If a user does not have enough votes to perform a particular
operation, he can append one or more proxies to his request to the
server.  A proxy is a certificate which is issued by the Nox server on
behalf of another user, authorizing the use of that user's access
``votes'' for the purpose of authorizing a particular request.

\begin{figure}
\begin{center}
\PSbox{/mit/tytso/thesis/proxy-prot.ps}{4.6in}{2.6in}
\end{center}
\caption{A sample conversation showing how proxies are used}
\label{proxyprot}
\end{figure}

The protocol which is used by an application on behalf of a user to
obtain a proxy from another user is application specific.  Typically,
the application (the ``beggar'') will send the complete request over the
network to the ``granter'' user --- for security, this exchange
would have to take place encrypted in a user-to-user session key, which
would have to be negotiated somehow.  If the granter user decides
that it wishes to allow his or her access rights to be used for the
particular request, he or she requests a proxy from Nox.  This request
contains the following information: the beggar who will ultimately
make the request, a cryptographic checksum of the entire request, the
number of votes for each access right that should be applied towards
the request, and an expiration time (to limit the lifetime of the proxy).
Nox seals the supplied information in a {\em proxy key} which is known
only by Nox and returns the proxy to the granter.  The granter
then forwards the proxy to the beggar who uses the
proxy to actually make the request.  Figure~\ref{proxyprot} shows a
sample transaction involving proxies.


When the Nox server receives a request, it checks if it contains any proxies
are present.  If so, it checks to make sure that the users who issued
the proxies are are all distinct from each other and from the user who
issued the request.  (This is to prevent users from ``stuffing the
ballot box'' by attaching two proxies from the same user in a request.)
Nox then sums up the number of ``votes'' for the access rights required
for the requested operation.  The minimum number of required ``votes''
for each access right is stored in the compartment (and can be modified
by a compartment administrator).  If the number of ``votes'' contained
in the request is greater than or equal to the minimum number of
required votes, then Nox will perform the request.


\section{Satchels}

Figure~\ref{satchelfig} shows a typical satchel that might be created by
Nox.  As figure~\ref{satchelfig} indicates, the satchel contains
three parts.  The first part consists of information which is stored in
the clear (i.e., not encrypted) in the satchel.  This information consists
of a structure tag/version number, which identifies the data as a Nox
satchel, and the name of the Nox server which sealed the satchel.

The second part of the satchel is encrypted in Nox's private key.  It
contains the name of the compartment to which the satchel belongs,
and version number of the compartment's encryption key that was used to
encrypt the third part of the satchel.  The compartment name and the key
version number identify the encryption key of the data.  The compartment
name is also used to identify the access control information which
determines who is allowed to decrypt that data in the satchel.  The
confounder is a random value which is inserted into the second part of
the satchel to prevent an eavesdropper from collecting a ``dictionary''
of the second part of the satchel which could be used to correlate this
part of the satchel with its compartment.  

The third part of the satchel contains the ``interesting'' data, such as
the user who created the satchel, the creation time of the satchel, and
the actual message.  In addition, built-in access control information can
optionally be included in the third part of the satchel; if present, it
overrides the the access control information of the compartment for that
satchel.  (Of course, not all access rights are meaningful in a ACL
embedded in a satchel.)  The satchel may also contain a sequence
number.  If the compartment has sequencing enabled, then each satchel,
when created, is assigned a monotonically increasing sequence number.
This sequence number is extremely useful in some applications, as we
will see in section~\ref{ssyslog}.  The confounder is also stored in
this part of the satchel to prevent the spoof attack where an intruder
interchanges the third part of two satchels.

\begin{figure}
\PSbox{satchel.ps}{6.0in}{4.08in}\hss
\caption{A Sample Satchel}
\label{satchelfig}
\end{figure}

\section{Compartment naming}

The compartments are named hierarchically, using {\em compartment
containers}.  Their function is like that of directories in a
hierarchical filesystem.  That is, each compartment container may hold an
arbitrary number of named compartments or sub-containers.  This
hierarchical arrangement allows for easier administration of
compartments, since, it is possible to give a user or group of users
control of an isolated branch of the hierarchy.

Each container has a quota which represents the maximum number of new
compartments which can be created in the container.  The quota can be
disabled (by setting it to -1).  When a new sub-container is created, if
the parent container had quotas enabled, then the user must specify a
quota for the new sub-container as well, which will be deducted from the
parent container.  Naturally, the quota of the parent container must
remain greater than zero or Nox will not allow the sub-container to be
created.  If the parent container has no quotas enabled, then the
sub-container may either have no quota or any user-specified quota
without any restrictions.

The compartment container has a generalized access control list with the
following access rights:

\begin{itemize}
\item Administrate --- this allows the user to add/delete/modify entries
in the container's ACL.

\item List --- this allows the users to list all containers and
compartments in this container.

\item Sub-container access --- this allows the user to create/delete
{\em any} sub-container.  This also allows the user to modify the quota of
the sub-container (subject to the constraints of this container's quota).

\item Create --- this allows the user to create a new compartment in
this container.

\item Delete --- this allows the user to delete a compartment in this
container. 

\item Manage --- this allows the user to enable or disable a
compartment in this container.   If a compartment is disabled, the Nox
server will not perform any requests for that compartment.  
The manage privilege also allows the user to
force the generation of a new key for the compartment.  (The rationale
behind this is that if the administrator discovers a breach, he
should be able to force the generation of a new key without needing to
notify the compartment administrator.) 

\item God --- This privilege allows the user to modify the ACL for any
compartment or sub-container.  This is extremely powerful, since someone
with this privilege will be able to read any satchel just by forcing
themselves onto the compartment's ACL.  This privilege level may only be
set or removed by a user who has both the Administrate and God
privileges.

\end{itemize}

Exactly how compartments are named is not important in examining how
compartments work or what security they offer.  Hence, we will not
discuss the compartment naming scheme further in this thesis.
