\chapter{Details of a Sample Implementation}

\begin{quote}
\begin{description}

\item[prototype, n.] ---
         First stage in the life cycle of a computer product, followed
         by pre-alpha, alpha, beta, release version, corrected release
         version, upgrade, corrected upgrade, etc.  Unlike its
         successors, the prototype is not expected to work.
\end{description}
\end{quote}

The following are some implementation notes for a planned reference
implementation of Nox.  

Communications between the server and the client will be done using an
RPC protocol, which will probably be a modified version of Apollo's
Networking Computing System (NCS).  It has the advantage of
being one of the more efficient RPC mechanisms available, and it has a
powerful interface compiler and stub generator.  It will need to be
modified so that some of the arguments of the RPC can be
encrypted in the connection's session key after they have been
marshaled by NCS.  Likewise, the arguments will have to be decrypted
before they can be unmarshaled by the RPC system.  I am told by Bill
Sommerfeld\footnote{An employee of HP/Apollo who is currently working on
NCS} that these modifications should be relatively simple to make.

When a client wishes to initiate a session with Nox, it sends a
connection request to the server, which includes the necessary
information to authenticate itself to the server using some specified
authentication method (Kerberos, for example.)  The server stores away
the following state per connection:

\begin{itemize}
\item A connection ID, which is unique with respect to the lifetime of
the server.

\item The user which has authenticated using the connection ID.

\item The host address from which the connection was initiated.

\item A session key which was generated from the authentication
sequence.
\end{itemize}

Nox returns a connection descriptor and a connection ID when a client
opens a connection with the server.  The connection descriptor is a
low-numbered integer which is used by the server to index into an array
of structures describing the connection.  When the server is first
started up, it picks a random number which is the initial connection ID.
This connection ID is incremented each time a new connection is opened
to the server.

Every time the client sends a request to the server, it includes the
connection descriptor and the connection ID in the packet; the rest of
the packet contains the request to the server and the appropriate
arguments for that request encrypted in the session key.  When the
server receives the packet, it uses the connection descriptor to get the
Connection Data Block (CDB) associated with the connection and compares
the connection ID supplied with the client packet to the connection ID
in the CDB.  If either the ID's do not match or the lifetime of the
authentication has expired, the server will respond with an error code
which asks the client to re-open a connection with the server and
retransmit the request. 

If necessary, the server can at any point invalidate a connection.  It
may need to do this if it has run out of CDBs when its opening a
connection with for a client and it has run out of free CDB.  In this
case, it will merely pick the CDB which has been used least recently and
assign it to the new connection.  The next time the old client tries to
use that connection descriptor (assuming the old client is still
running!), the connection ID which has will no longer match the
connection ID in the CDB, and the server return an error indicating that
the client should open a new connection to the server.

The following is a list of requests that the server will support on
compartments:   (Note: these requests are not yet fully defined yet;
for example, what exceptions have not listed here, and need to be at
some point\ldots) 

\begin{itemize}
\item Encrypt --- client sends subject, data and optional Built-in ACL;
server returns a satchel encrypted with a the specified compartment.
Requires Encrypt and optionally Build-In ACL access.

\item Decrypt --- client sends satchel and bit-field corresponding to
Identify, Examine, and Decrypt actions; the server returns the requested
data.  Requires Identify, Examine, and/or Decrypt access.

\item Status --- server returns the current key version number, the last
modification time of the compartment and the ACL of the compartment.
Requires Status access. 

\item New Key --- server creates a new key for the compartment, and
returns the new current key version number.  Only the master Nox server
supports this query, and at some point will arrange for the new keys (or
perhaps the entire database) to be distributed to all of the slave
servers, probably encrypted in the Nox master server.  Requires
Administrate access.

\item Set Acl --- client sends a principal and a list of access rights;
the server will set the ACL on the compartment to have those access
rights.  Requires Administrate access.

\item Delete Acl --- client sends a principal; the server will delete
that principal from the compartment's ACL.  Requires Administrate
access.  (Note that because of wild-carding, setting the ACL for a
principal to have null access rights and deleting a principal from an
ACL have entirely different semantics.)
\end{itemize}

The following is a list of request that the server will support on a
compartment container:

\begin{itemize}
\item List --- the server returns a list of names of the containers and
compartments contained in the specified container.  Requires the List
access right.

\item New --- the client passes the name of the new compartment; the
server creates the compartment, placing the principal with which the
client authenticated with the server on the compartment ACL with full
access rights, including Administrate.  Requires the Create
access.

\item Remove --- the client passes the name of the new compartment; the
server destroys that compartment.  Note that this will make any satchels
which were encrypted in that compartment permanently useless, so this
operations should not be done lightly.  Requires the Delete
access.

\item Make Compartment --- the client passes the name of the new
sub-container, the initial quota of the sub-container and a flag
indicating whether or not the ACL of the new sub-container should
contain just the user creating the sub-container or whether the ACL
should be copied from the parent container; the server creates the
sub-container, with the appropriate ACL.  Requires the Sub-container
access. 

\item Delete Compartment --- the client passes the name of the
sub-container to be deleted; the server will delete the sub-container if
it is empty.  Requires the Sub-container access.

\item Set Quota --- the client passes the name of the sub-container and
its new quota; the server will set the quota of the sub-container,
modulo the rules on quotas detailed elsewhere.  Requires the
Sub-container access.

\item Disable --- The client passes the name of a compartment; the
server will disable the compartment.  Requires Manage access.

\item Enable --- The client passes the name of a compartment; the
server will enable the compartment.  Requires Manage access.

\item Force ACL --- The client passes the name of a compartment, a
principal, and a list of access rights; the server will forcibly set the
supplied principal to have the specified access rights on that
compartment.  Requires God Access. 

\item Deify --- The client passes a principal and a container; the
server will grant the principal god access for that container.  Requires
God access on either the container or in the parent container.

\end{itemize}


The encryption containers and encryption compartments can be easily
modeled by the Unix$^{\hbox{TM}}$ filesystem.  Each encryption container
can be modeled as a directory, with its access control file stored in
the file ``$>$ACL'' (which will not conflict with potential compartment
names since the $>$ character is not allowed in either compartment or
container names.)  All of the state of an encryption compartment will be
stored in a file, in the appropriate directory corresponding to its
parent container.

