Security Considerations

The X-Bone changes the configuration of remote machines automatically on behalf of users. This requires strong authentication and encryption mechanisms to prevent abuse. The first part of this document focuses on security issues in the management system.

The X-Bone can also optionally deployed secured overlays. Security issues related to the deployed overlays are discussed in another section of this document.

The following basic assumptions apply to the X-Bone security mechanisms:

• Any required storage is unencrypted with root-only access. The root user has full control over all system parameters used by the X-Bone, and can obtain the information stored through other means.
• Nodes participating in multiple overlays act as crossover points. If an attacker gains root access to a machine that is part of one or more overlays, all overlays are compromised.

Management System Security

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

• 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 front ends.)
• A resource daemon (RD) controls access to configuration of networked resources (routers, hosts, and links), according to an ACL configuration set by resource owner.
• An overlay manager (OM) is an intelligent agents that acts on behalf of users, gathering and coordinating the resources required for an overlay by communicating with resource daemons.

X-Bone security mechanisms use strong cryptography based on X.509 certificates. SSL is used to authenticate and encrypt all TCP-based communication, and S/MIME is used to authenticate and encrypt all unicast UDP communication. Multicast UDP messages are only authenticated, not encrypted. Two-way authentication is enforced; specifically, SSL's one-way authentication mode is never used.

X.509 has a hierarchical trust model with designated, well-known certification authorities (CAs). A principal considers a peer's certificate to be valid (thus authenticating the other party) if and only if a signature chain exists that contains a signature by a CA the principal trusts. The X-Bone project acts as a CA for all X-Bone-related keys. Keys certified by other well-known CAs may also be used (configurable).

Communication Overview

During a typical X-Bone transaction, a user will contact an OM, which parses and executes the user's request. The OM then executes sub-transactions with some RDs, carrying out the user's request. Eventually, the OM will return some information to the user, finishing the transaction.

Note that users (and front-ends) do not construct the required commands to coordinate an overlay. The OM is the intelligent party that coordinates overlay deployment on behalf of a user. So, although an RD controls access according to end-user identity (e.g. an ACL allows "xb-admin@isi.edu" to set up tunnels), the user (or user front-end) itself does not issue those commands.

Thus, transitive trust is required: Both the user and the RDs trust that the OM will construct commands that implement the user's intent, and that the OM will not exploit user authentication to construct some other overlay for some other purpose.

User-to-OM Communication

Users communicate with an OM through an application programming interface. SSL is used for this communication, providing two-way authentication and encryption. Currently, two methods for communication are supported:

In the first case, users (or applications with access to the user's certificate) directly open a connection to an OM. In this case, the user and OM directly authenticate one another over SSL.

In the second case, a web interface provides a graphical user interface (GUI) to the user, who accesses this GUI through a web browser over secure HTTP/S (which in turn is based on SSL), and the GUI then communicates to the OM.

The second case again requires transitive trust: The user contacts and authenticates herself to the web server implementing the GUI, which in turn uses its own certificate to authenticate itself to the OM.

In both cases, all communication occurs over two-way authenticated and encrypted SSL connections.

OM-to-RD Communication

During the second part of an X-Bone transaction, the OM will communicate the user's request to a number of RDs.

For one set user requests, the OM uses SSL to communicate with a single RD. As before, the OM and RD use two-way authentication and encryption to secure this communication.

Another set of user requests involve UDP multicast and unicast messages. Multicast messages are currently only authenticated, but not encrypted, and thus are transmitted in the clear. Unicast UDP messages are both authenticated and encrypted.

RDs and OMs provide replay protection for UDP messages. This safeguards against both packet duplication and malicious replay. (SSL-secured TCP traffic is inherently protected against replay.)

RDs employ access control lists based on user identifiers to limit access to their resources.

Overlay Traffic Security

The X-Bone can optionally deploy secure overlays, also called virtual private networks (VPNs). For such overlays, the IP tunnels providing overlay links are secured with IPsec. A user can choose on a per-overlay basis whether links are authenticated, encrypted, both authenticated and encrypted or unsecured. For authenticated or encrypted overlays, the user also chooses IPsec algorithms to provide security on a per-overlay basis.

Unimplemented Features

The current implementation does not implement some of the security features present in the architecture described above. These features are currently not implemented, but will appear in a future release:

• Communication between the GUI web server and the OM is currently not transmitted over SSL. To provide some level of protection, the GUI and OM can currently only be deployed on the same machine, and the OM only communicates over the loopback interface with processes running as the root user.
• All UDP communication is currently unencrypted (but authenticated). This allows an attacker to gain additional information about who is deploying overlays.
• For secure overlays, the OM distributes shared keys for each tunnel at setup time. These keys currently remain unchanged over the lifetime of the overlay. The Internet Key Exchange (IKE) protocol should be employed to avoid centralized key management, and enable rekeying.