===============================================================================
                             X-BONE SECURITY MODEL
                           http://www.isi.edu/xbone/
                                xbone@isi.edu

                                Lars Eggert
                              $Revision: 1.1 $   
                        $Date: 2000/07/27 01:23:59 $
===============================================================================


1. INTRODUCTION

There are three principle groups of agents in the X-Bone system:
users, overlay managers (OMs), and resource daemons (RDs).

	Users have specifications for an overlay they want deployed
	and have unsophisticated front-ends that allow expression of
	specs, but cannot make decisions. (Currently, COTS web
	browsers are X-Bone frontends.)

	OMs are intelligent agents that act on behalf of users to
	gather and coordinate the resources required for an overlay.

	RDs control access to configuration of networked resources
	(routers, hosts, and links), according to an ACL configuration
	set by resource	owner.

X-Bone security mechanisms currently use public-key
cryptography. Candidate users, OMs and RDs need to generate key pairs,
and have their public keys signed by one of the certification
authorities accepted by X-Bone before participating. Two-way
authentication is enforced; encryption is optional but encouraged.

During a typical X-Bone transaction, a user will contact an OM which
will parse and (pending authorization) execute the user's request. In
turn, the OM will execute sub-transactions with some RDs. Eventually,
the OM will return some information to the user, finishing the
transaction.

Important to note is that users (and front-ends) do not construct the
required transactions necessary to coordinate an overlay. So, although
an RD will control access according to end-user identity (e.g. an ACL
will allow "xb-admin@isi.edu" to set up tunnels), the user (or user
front-end) itself does not issue those commands. The OM is the
intelligent party that coordinates overlay deployment on behalf of a
user. Third-party trust is required: both the user and the RDs must
trust that the OMs will construct commands that implement the user
intent (and that the OMs will not exploit user authentication to
construct some other overlay for some other purpose).

X-Bone security is based on third-party trust, where (1) users and OMs
authenticate themselves to each other, and (2) OMs and RDs
authenticate themselves to each other. User credentials are passed to
the RDs by an OM for ACL checks; however, this still presumes trust
that the credential and the requested configuration transaction belong
together. These two components of a request cannot be atomic if the
user's front-end agent and the OM are separate entities. Lack of
atomicity requires delegated trust.

The X-Bone security mechanisms are based on X.509 certificates. SSL is
used as a secure communication channel whenever peers need to exchange
information.


2. CERTIFICATION AUTHORITY (CA)

All public keys need to be signed by some CA in order to be
trusted. The X-Bone project acts as a CA for all X-Bone-related
keys. Keys certified by other well-known CAs may also be accepted
(configurable).

SSL has a hierarchical trust model with design ated, well-known CAs. A
certificate is considered valid (thus authenticating the other party)
if and only if a signature chain exists that contains a signature of a
trusted, well-known CA.


3. USER-TO-OM SECURITY

By design choice, X-Bone users communicate with the OM through a set
of web forms and pages. Users run a web browser of their choice, and
part of the OM is a web server. Thus, providing two-way authentication
and security for this part of an X-Bone transaction is equivalent to
providing secure, authenticated HTTP. COTS web browsers were chosen as
user frontends, because they are widely available for numerous
platforms and most already support HTTP/S (which is built on top of
SSL) on many platforms. Free web servers supporting HTTP/S are also
available (apache-ssl).

Current implementation of X-Bone does *not* distinguish overlays created
by different users on the same OM. The creater information is listed in the 
overlay monitoring page, but anyone *can* delete anyone else's overlays.


4. OM-TO-RD SECURITY

During the second part of an X-Bone transaction, the OM will
communicate the user's request to the affected RDs by sending resource
discovery messages to the multicast group associated with an
overlay. RDs will respond using unicast messages. Again, two-way
authentication is required and encryption desired. After the OM has
found enough resources to satisfy the user's request, it will then
send unicast configuration messages to each RD. This second phase is
again secured by using SSL. Securing the first part (multicast) is
more difficult.

SSL does not support multicast traffic, since it is built on top of
(unicast) TCP. However, the X.509 key pairs SSL uses can be the base
of a simple, PGP-like public-key encryption and authentication
system. (PGP does not support X.509 keys, and thus cannot be used here
unfortunately.) OpenSSL is a free tool that can be used to that
purpose. Alternatively, SSL could be extended to support an initial
many-to-many handshake to set up multicast distribution.

The current version of X-Bone does not secure (neither authenticate
nor encrypt) the initial multicast resource discovery requests and
responses. However, this does not pose a significant security risk,
since the resource discovery messages to not cause an RD to perform a
priviliged action. They simply cause it to see if it could participate
in the announced overlay, and maybe trigger a response message. If the
OM picks a particular RD for participation, it will send its
configuration commands using secure, authenticated SSL, and an OMs and
RDs have then the opportunity to verify each others' credentials.

Not signing and encrypting the multicast resource discovery messages
exposes the following things to a possible attacker:

	1. address/location of RDs
	   If the multicast messages were signed, an RD would not
	   respond to a forged resource diuscovery request, keeping
	   its presence unknown to an attacker.

	2. overlay creations
	   By reading the multicast request message, an attacker can
	   learn which users try to set up overlays of a certain size
	   and topology. By reading the responses, an attacker can
	   generate a superset of possible overlay hosts.

	3. denial-of-service attacks
	   By posing as a OM, an attacker can flood RDs with resource
	   discovery requests and trigger unicast responses that may
	   overload the RDs. By posing as an RD, an attacker could
	   make overlay creation fail by sending fake responses.
	   (However, the OM can detect this after the first creation
	   process failed.)
