\chapter{Extensions}
\label{chap:extensions}

\section{Replicated Servers}
\label{multiserver}

There are several problems which might require the replication of the
Nox servers.  The first problem is that a single Nox server may become
overloaded and prove to be unable to handle all of its clients' demands.

There are several solutions to this problem.  One solution is to divide
the compartments serviced by the Nox server so that half of the
compartments are serviced by one server and the other half are serviced
by another.  However, while this solution solves the load
problem, it does not address the problem of reliability.  Since only one
entity --- the Nox server --- 
knows the encryption keys, if a client cannot communicate to the server, 
either because the network has been partitioned or because the Nox server
has crashed, any satchels in the client's possession become useless for 
the duration of the downtime.

Both of these problems can be solved by replicating the Nox servers.
Thus, as long as the clients can reach one of several servers, service
will not be lost.  However, replicated servers have other problems.
First of all, all the servers have to be physically secure; if any one
of the servers are compromised, the all of the satchels are compromised. 

The second concern with replicated servers is that the databases on all
of the servers must be kept consistent.  One way of doing this is to
designate one of the servers as the master server.  (Kerberos
uses a similar approach.)  Under this scheme, changes can only be made
if the client can reach the master server.  In addition, because of
network partitioning, some of the slave servers may not be immediately
reachable by the master server.  Thus, there may be some lag for changes
to propagate.\footnote{This may cause some problems in that an intruder
maybe able to disable a gateway and keep a slave server isolated from
the master server.  Thus, if the intruder knows that his access is about
to be revoked, he may be able to delay the revocation of his access
rights for a time.  We will need to assume that the gateway is
relatively well protected, and that the loss of service caused by the
gateway being down will attract attention relatively quickly.}

A final problem which must be dealt with is compartments which have
sequencing enabled.  In these compartments, each satchel which is
created by Nox must be uniquely numbered (in a monotonically increasing
fashion).  This is extremely difficult to coordinate in a
multiple-server environment, since different servers may be creating
satchels at the same time, thus making it difficult to assure that all
of the satchels have an unique sequence id.  There are two solutions to
this problem.  The first is to allow only the master Nox server to
encrypt satchels in compartments which have sequencing enabled.  This
allows the sequence id to be kept consistent, because only one server is
updating it at any one time.  The second solution is much more
complicated, but is perhaps cleaner.  In this solution, any Nox
server can create satchels (and thus modify the sequence id of the
compartment) as long as it can contact at least a majority of the
servers and it lock the sequence id amongst the quorum of servers.
While this solution makes it less likely that the Nox service will be
unable to create satchels because one or more servers are down, the
inter-server protocol is much more complicated, and thus more vulnerable
to coding errors.  

\section{Inter-realm operation}

While replicated servers allow a larger number of compartments and Nox
clients to be supported by the Nox servers, it may also be advantageous
to have several Nox servers which are under separate administrative
controls.  For example, separate sets of Nox servers would be required
for each company and university (or university department) which wishes
to use Nox.  Each Nox server (or replicated group of servers) at one
site constitutes a Nox {\em realm}.\footnote{much like a Kerberos realm
in the Kerberos authentication system}  The problem of inter-realm
operation comes up when an application at one site wishes to send
information secured by Nox to another site.

If there is a fast network connecting the two realms, inter-realm
operation is straightforward.  In this case, the application only needs
to use the inter-realm authentication procedures provided by the
authentication system to authenticate to the remote Nox server.
Using this authentication, the remote-realm client can then contact the
Nox server directly using the network, and proceed as any other local
client.

Unfortunately, there is often no high speed network between the two
sites.  For example, communications between two sites might be restricted
to UUCP\cite{UUCP} using a 2400 baud modem.  When the application
receives a satchel which was created by a Nox server which cannot be
easily reached, it will not be 
able to contact the remote Nox server in order to decrypt the satchel in
real time.  Another problem is that it is often difficult to build an
authenticated connection over an extremely slow, batched link,
especially since clock synchronization is usually not possible.

Some of the above problems could be solved if the local Nox server
possessed the encryption keys used by the foreign Nox server when it
created the satchels sent to the local Nox server.  However, this
violates one of the central assumptions of Nox, which is that only one
entity knows the encryption keys used to create the satchels.  This is
why the case of inter-realm operation where there is no fast network is
a hard problem.

In order to solve the multiple realm problem, we must first begin by
identifying the trust 
assumptions which must be made in a multi-realm environment: 

\begin{itemize}
\item {\bf The foreign Nox service is trust-worthy.}  Since the
foreign user will not be able to contact the Nox server which created
the satchel, the only way the user will be able to obtain the contents
of the satchel will be if the satchel which the user receives can
somehow be decrypted by the foreign Nox server.  (There are different
schemes which will allow the foreign user to read a satchel which was
not encrypted in his realm (which will be discussed later), but all
of the schemes require the foreign Nox server must be able to decrypt
the satchel.)

\item {\bf The foreign authentication service is trust-worthy.}  For the
same reasons that the administrators of the foreign Nox server must be
trust-worthy, the foreign authentication service and its administrators
must also be trusted, since Nox depends on the authentication service for
its security.

\end{itemize}

With these assumptions in mind, a multiple Nox server protocol can be
built as follows: Each Nox server (or each set of replicated servers)
has authority over a Nox realm, which are 
distinct from any authentication realm.  In order to allow one Nox
server to read the satchels that originated from another Nox server, the
administrators of the two Nox servers exchange private keys.  Since this
requires the cooperation of the administrators of the two Nox servers,
this key must have been exposed at one point or another {\em outside}
the Nox servers themselves.  Thus such an inter-realm exchange satchel
will be inherently less secure than a satchel which is intended for
intra-realm use only.


If a Nox client wishes to send a satchel to the remote Nox realm, it
must contact the local Nox server and ask the Nox server to reseal the
satchel in the private exchange key for the remote Nox realm, which it
can then send to the remote Nox realm, thus creating an inter-realm
exchange satchel.  Since the remote Nox server has no knowledge about
the state of the local compartment, the access control information which
is stored in the compartment must be included in the inter-realm
exchange satchel.  This implies that 
once the exchange satchel is created by the Nox server, the access
control information is frozen inside the satchel, and any remote users'
access to that satchel can not be later revoked.  Note that the local
Nox server can only  assume that the remote Nox server will honor the
access control information stored in the satchel; if the remote Nox
server or its administrators are untrustworthy, the contents of the satchel
could be compromised.

In this proposed extension, when an administrator sets the ACL of his
compartment to grant decrypt access to a foreign Nox realm, this
automatically decreases the security of his compartment to the combined
minimum security of the local and remote realms.  This is because once a
foreign user appears on the access control, the Nox server will be
willing to generate an exchange satchel to allow the foreign user to
access the compartment.  However, if the foreign Nox server has been
compromised, then that compartment's security will also be compromised. 

As we can see, it is extremely difficult to provide inter-realm
operability of Nox between two sites that do not have a fast network
connecting them.  While the above extension provides a partial solution,
it loses some of the flexibility that Nox would normally offer and with
the cost of a lot of complexity.  Further research is indicated to
refine this solution, and to determine whether or not inter-realm
operations under these adverse conditions in worth implementing.

\section{Mandatory Access Controls}
\label{MLS}

Non-discretionary access controls, or mandatory access controls, are
difficult to implement in a distributed system, since the workstations
generally can not be fully trusted.  This causes a problem because once
the contents of the satchel is decrypted and sent to the workstation,
there is nothing to prevent the software from broadcasting the
information at a lower security level.  However, Nox may be able to
serve as part of a multi-level secure system (MLS) which has a trusted
network interface to prevent sensitive information from being
compromised at a lower security level.  Further research is indicated to
determine how the Nox system would function in such an environment.

% 
% Local variables:
% version-control: t
% make-backup-files: t
% mode: TeX
% End:

