I've finally met with a laywer, and now I'm comfortable discussing
plans for security. I'll open with a draft white paper I have written
which attempts to outline things, and hope to generate some discussion
(it lacks detail, but is appended below). My hopes regarding export
regulations are as follows.
The system will use authentication only, built upon the openssl library,
which is available from outside the U.S. Though SSL contains support for
encryption, it will be disabled by selecting a NULL encryption cipher
(which uses only a MAC, no confidentiality). It is our belief that since
PRCS will not itself contain any crypto code, and since it is only
uses authication, it will not be classified as an Encryption Item, and
it can be freely exported. I will obtain a formal opinion statement from
another lawyer (my next legal fee) before going too far, for protection in
case the BXA makes any action.
The current state of things is: large body of code, including a client
and server framework built upon SSLeay-0.9b's async I/O calls. There is
little work to be done integrating SSL, only in implementing policy.
I will upgrade to openssl at their next release. There is no application-
level security policy yet, because I have not started working on it, and
I have to admit I've been somewhat puzzled every time I attempt to figure
out how to start implementing it within SSLeay. As has been discussed on
the PRCS mailing list, I am willing to accept help implementing security,
and there are outstanding offers of at least U.S. $1000 to begin funding
this work, and I'm confident that other donations will arrive if progress
can be shown by another programmer.
-josh
PRCS SECURITY WHITE PAPER
This note describes the application security policy for PRCS. It
specifies the functional requirements on the manipulation of trust and
identity in the system. To begin with, I will list the important
entities involved;
DEFINITIONS
-- A _USER_ is an end-user of the prcs client, identified by a
public/private keypair. A user could obviusly possess multiple
identities, and this should be easily supported by all
application key-management utilities.
-- A _PROJECT_ identifies, by name, a set of project versions. There
is, however, no actual identity associated with a project itself,
because authetication is handled at the branch level. Therefore,
a project is simply identified by its name. To prevent naming
conflicts, an additional serial number will be issued to maintain
uniqueness amongst similarly named projects.
-- A _SERVER_ is an instance of a PRCS repository, and is identified
by a public/private keypair. Each server manages a single
repository, which can be configured in a variety of ways. The
server can act as a proxy-cache, replicate collections of data
in other repositories, administer responsibility for local
branches, handle access control, etc.
-- A _BRANCH AUTHORITY_ is the server owning authority for a branch.
-- A _BRANCH_ contains a subset of project versions belonging to a
particular project. For example, the branch named "B" contains
a numbered sequence of versions B.1 through B.N. Each branch
is owned by a single server, its branch authority. A branch is
identified by a public/private keypair, which is used to
authenticate transactions involving the branch.
-- A _PEER_ refers to another server, identified by its public key
and IP address. Collectively, a server and the transitive closure
of its peers comprise a repository network, and there are several
ways of administrating trust in the network.
ACCESS CONTROL
Access control lists will be used for controlling read and write
access to project versions. Each branch will have an associated ACL,
maintained by its branch authority, which maps the fingerprint (SHA-1)
of a public key into the capabilities to be granted to a user or peer.
There are two security policies which may be applied to a particular
branch and installation, depending on whether anonymous public access
is desired for the branch. Depending on whether anonymous public
access is desired, there may be additional trust requirements applied
to all peer relationships.
There must exist user interfaces and protocols for conveniently
maintaining these lists, including identity and priviledge aliasing
and grouping, and from both the repository administrator and user's
point of view. Whether existing protocols, specifications, or formats
for these tasks are re-used or not, I do not mind.
CAPABILITIES
For each branch,
-- The _WRITE_ capability grants to a user the priviledge of
checking-in a new project version
-- The _READ_ capability grants to a user the priviledge of
checking-out an existing project version
-- The _SYNCPUSH_ capability grants to a peer the priviledge of
sending for replication the contents of any files belonging to the
branch during a synchronization
-- The _SYNCPULL_ capability grants to a peer the priviledge of
requesting the contents of any files belonging to the
branch during a synchronization
All capabilities may be granted to the anonymous public, yet the
transitive nature of trust makes many configurations illogical.
TRUST in PROXYING and REPLICATION
Depending on the availability of trust, a server may be set up to
proxy the PRCS protocol and replicate data amongst its peers. If a
server S has the SYNCPULL capability registered with its peer P,
then S may initiate a synchronization with P. P may wish to
synchronize with S as well during the same connection, if it has the
capability registered with S. The synchronization protocol is a
server-to-server protocol that (bi-directionally) transfers files
according to each server's policy regarding the peer in the manner
described by my paper on XDelta (it transfers deltas when possible,
then uses rsync when possible).
When a server is not the branch authority for a branch which it would
like to serve, it is configured with a link to another machine which
serves the branch. The other machine is known as the _BRANCH LINK
LOCATION_, and need not be the branch authority. In order to
establish a branch link, the server must have the SYNCPULL capability
with the branch link location.
When a server has a branch link, it may be configured to cache and
replicate the data belonging to the branch. It may used this data to
handle read requests by its clients. Data is replicated between
repositories by periodic push and pull synchronization requests
between peers according to each server's configuration.
If read data for a branch being served is not available in a server's
cache, then the server requests it at the branch link location. If
the branch link location cannot serve the request, it follows its own
branch link location. The branch authority is responsible for either
having all branch data, or delegating that responsibility to another
server, in which case the authority responds with a redirection.
Eventually, the request will reach the branch authority or one of its
delegates.
Write operations (checkins) require more handling, since they require
communication with the branch authority. When a client connects to
server S to checkin, and S is not the branch authority, then it
proxies the checkin request to its branch link location using a
modified checkin protocol. The chain of requests proceeds with the
client's new project version file until it reaches the branch
authority. The branch authority initiates a checkin transaction, and
replies with an authentication challenge and a list of file versions
the server requires to complete the transaction. The client answers
the challenge and sends the files. When a branch authority has
delegated storage authority to another peer, that peer may accept file
versions on behalf of the authority (and forward a notice to the
branch authority that it has done so, in order to complete the
transaction).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
