--- /dev/null
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+<article>
+ <articleinfo>
+ <title>PlanetLab Boot Manager</title>
+
+ <author>
+ <firstname>Aaron</firstname>
+
+ <surname>Klingaman</surname>
+
+ <email>alk@cs.princeton.edu</email>
+ </author>
+
+ <affiliation>
+ <orgname>Princeton University</orgname>
+ </affiliation>
+
+ <abstract>
+ <para>This document outlines the design and policy decisions of a new
+ PlanetLab component called the Boot Manager. The Boot Manager
+ encompasses several systems and all policy regarding how new nodes are
+ brought into the system, how they are authenticated with PlanetLab
+ Central (PLC), what authenticated operations they can perform, and what
+ constitutes a node's identity.</para>
+ </abstract>
+
+ <revhistory>
+ <revision>
+ <revnumber>1.0</revnumber>
+
+ <date>January 14, 2005</date>
+
+ <authorinitials>AK</authorinitials>
+
+ <revdescription>
+ <para>Initial draft.</para>
+ </revdescription>
+ </revision>
+ </revhistory>
+ </articleinfo>
+
+ <section>
+ <title>Overview</title>
+
+ <para>This document describes the history of and groups several previously
+ separate, undocumented components and policy decisions of the PlanetLab
+ infrastructure into one logical group, which will be called the
+ <firstterm>Boot Manager</firstterm>. In addition, specific recommendations
+ are made for changes and additions to these parts to support new features
+ and better security outlined in detail later. These include:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>How new nodes are added to the PlanetLab system, and the chain
+ of trust that accompanies that addition</para>
+ </listitem>
+
+ <listitem>
+ <para>How to prevent unauthorized nodes from becoming part of the
+ system, and the consequences of that happening</para>
+ </listitem>
+
+ <listitem>
+ <para>How any existing node authenticates itself with PlanetLab
+ Central (PLC), and what operations can it perform</para>
+ </listitem>
+
+ <listitem>
+ <para>What constitutes node identity, and, when this identity should
+ and should not change</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Not covered by this document are topics including node to node
+ authentication, or any service or system running after a node is fully
+ booted and the Boot Manager is no longer applicable.</para>
+ </section>
+
+ <section>
+ <title>Terminology</title>
+
+ <para>Before continuing, terms used through this document, including what
+ a site is, what nodes are, and what PlanetLab consists of will be defined.
+ Current organizational structure consists of groups of
+ <firstterm>sites</firstterm>, usually a geographical location
+ corresponding one to one with a company or university. These sites have
+ any number of <firstterm>users</firstterm> or
+ <firstterm>researchers</firstterm>, including a <firstterm>principle
+ investigator</firstterm> , or <firstterm>PI</firstterm>, responsible for
+ the users, and one or more <firstterm>technical contacts</firstterm>.
+ Sites are usually composed of at least two machines running the PlanetLab
+ software, usually referred to as <firstterm>nodes</firstterm>. All user
+ and node management operations are done through a set of servers located
+ in one physical location which is known as <firstterm>PlanetLab
+ Central</firstterm>, or <firstterm>PLC</firstterm>.There are also a set of
+ PlanetLab <firstterm>administrators</firstterm>; not necessarily
+ affiliated with a particular site. <firstterm>PlanetLab</firstterm> then
+ collectively refers to all sites and their nodes and users, and PlanetLab
+ Central.</para>
+ </section>
+
+ <section>
+ <title>Background</title>
+
+ <section>
+ <title>How Sites Become Part of PlanetLab</title>
+
+ <para>A full discussion and evaluation of the process and security
+ implications of sites becoming part of PlanetLab is outside the scope of
+ this document. It will be assumed that the process is relatively secure,
+ and that user and PI accounts at that site are legitimate. However, it
+ is necessary to provide some basic information about the process.</para>
+
+ <para>What does it mean for a site to be part of PlanetLab?
+ Primarily:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>The site's record (e.g. name, url, geographical location,
+ contact information) is in the PLC database</para>
+ </listitem>
+
+ <listitem>
+ <para>There are a set of users (their email address, password,
+ personal information) associated with the site in the PLC
+ database</para>
+ </listitem>
+
+ <listitem>
+ <para>The ability for those users and PIs to perform some operations
+ at PLC, and gain direct access to the nodes</para>
+ </listitem>
+ </orderedlist>
+
+ <para>The process for allowing new sites to become part of PlanetLab has
+ been continually evolving since the beginning of PlanetLab. Initially,
+ the first sites were selected and invited, and record of their existence
+ in PLC was entered in by hand by an administrator. With a site now part
+ of PlanetLab, users and PIs at those sites could then register for
+ accounts to perform operations at PLC. Privileged accounts, such as PI
+ accounts, were enabled by administrators. At the time, this
+ administrative overhead was not a problem given the relatively limited
+ number of total sites.</para>
+
+ <para>Over time, parts of these operations have been streamlined. Now, a
+ site can submit all their relevant info on the PLC website, for review
+ and approval by administrators. They also no longer require an explicit
+ invitation. With the creation of the PlanetLab Consortium, there is now
+ an additional paperwork step before a site becomes a member of
+ PlanetLab.</para>
+
+ <para>With the introduction of the additional consortium step, the
+ process now exists as:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>A site either requests to join PlanetLab by contacting
+ administrators over email, or through other external
+ communication</para>
+ </listitem>
+
+ <listitem>
+ <para>Necessary consortium paper work is signed by all
+ parties</para>
+ </listitem>
+
+ <listitem>
+ <para>PI(s) submit connect (join) requests with remaining site and
+ personal information</para>
+ </listitem>
+
+ <listitem>
+ <para>Administrators verify that the PI is who they say they are,
+ and enable their site and accounts at PLC</para>
+ </listitem>
+ </orderedlist>
+ </section>
+
+ <section>
+ <title>How Nodes Become Part of PlanetLab</title>
+
+ <para>After a site has been approved and added to PLC, they are required
+ to install and make available to other users at least two nodes (as per
+ current policy).</para>
+
+ <para>In the first revisions of the PLC software, nodes were only added
+ to the system by hand. Usually a PI or technical contact would
+ communicate the network settings of the node, and it was then added to
+ PLC by an administrator. This prevented any nodes that weren't part of
+ PlanetLab to be recognized by PLC. No mechanisms existed to ensure that
+ the node's network (effectively its identity) was not hijacked by
+ another machine.</para>
+
+ <para>Since the beginning of PlanetLab, there have been little to no
+ restrictions on what machines the PlanetLab software can run on. This is
+ primarily due to the fact that all source code is now available, and it
+ is technically feasible for anyone to bring up a machine that is running
+ the PlanetLab software, or closely resembles it. What is important,
+ however, is when these nodes become recognized by PLC, and then
+ available to the users via PLC. Otherwise, a user would have to go
+ through non-PLC channels in order to find these nodes. Even then, they
+ could not use PLC to run their experiments on the nodes, because PLC
+ does not know about those nodes.</para>
+
+ <para>When a node becomes part of PlanetLab, it:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>Is recognized by PLC as being at the site by its existence in
+ our database</para>
+ </listitem>
+
+ <listitem>
+ <para>The existing node boot mechanisms allow the machine to come
+ online after communicating its identity to PLC</para>
+ </listitem>
+
+ <listitem>
+ <para>Researchers can use the node for their experiments by using
+ administrative interfaces at PLC</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Rather than adding each node by hand, the current system instead
+ allows for an entire network subnet to be authorized to contain nodes.
+ When a site joins, a PLC administrator authorizes the subnet the nodes
+ will be on, and any machines on that network are allowed to become
+ recognized by PLC automatically. This had immediate advantages,
+ primarily being one of not requiring overhead for PLC administrators to
+ add each node by hand as was done in the beginning. Given that a common
+ interest was to see PlanetLab grow in terms of number of nodes (as one
+ metric), the assumption was made that allowing any node to come online
+ on an authorized subnet without explicit approval from an administrator
+ or PI would benefit everyone.</para>
+ </section>
+
+ <section>
+ <title>Node Installation</title>
+
+ <para>To date, there have been three major revisions of the software
+ that installs a PlanetLab node. Not only have the mechanisms in which
+ the nodes get installed changed, but, under what context the
+ installation is running.</para>
+
+ <para>The first revision of the installer was primarily nothing more
+ than a customized RedHat (version 7.3) boot disk, with a PlanetLab
+ specific post script to perform final initialization steps. The network
+ settings, and which packages to install were all stored on the disk, so
+ a custom disk was generated on demand for each node. Anyone with one of
+ these disks could install a PlanetLab node.</para>
+
+ <para>The second revision of the installer was released in conjunction
+ the release of the new PlanetLab boot cd. The intention was not
+ necessarily to have the node packages on the cd (as they would quickly
+ go out of date), but, to provide a mechanism to allow administrators to
+ regain control of a machine, in the event that the node was compromised,
+ or the installed software was corrupted. The nodes were configured to
+ always start off the cd, and, rather than have a custom cd per node, the
+ network settings were stored on a floppy disk. Both the floppy disk and
+ the boot cd were to remain in the machine at all times. The RedHat
+ installer, Anaconda <citation>1</citation>, that was used prior to the
+ boot cd was modified to run in the context of this boot cd. This allowed
+ us a great deal of flexibility, as the cd was built so that all it would
+ do was:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>Bring a full Linux system online, running only off the
+ cd</para>
+ </listitem>
+
+ <listitem>
+ <para>Load any network and other drivers necessary, based on the
+ hardware of the node</para>
+ </listitem>
+
+ <listitem>
+ <para>Configure the network interface with the settings from the
+ floppy disk</para>
+ </listitem>
+
+ <listitem>
+ <para>Contact a special PLC boot server, and download and execute a
+ script.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>The boot cd uses HTTPS to contact the boot server, and uses a
+ certification authority (CA) certificate to verify the identity of the
+ machine at PLC. This way, it can be assured that the installation of a
+ particular node is correct, in at least that all packages originated
+ from PLC. The script downloaded by the boot cd for a node depends on the
+ current state of that node, in the PLC database. The PLC database must
+ identify the node in order to accomplish that. That is covered below, in
+ Node Identity.</para>
+
+ <para>The third and current version of the installer still runs in the
+ context of the boot cd, but was a complete rewrite to better handle
+ packages, and remove much unneeded complexity in the previous
+ installer.</para>
+ </section>
+
+ <section>
+ <title>Node Identity</title>
+
+ <para>In the first revisions of the PlanetLab software, nodes were
+ solely identified by their network settings, primarily, the hostname and
+ the physical address of the network adapter (MAC address). This worked
+ well then, as this set of information was unique, and allowed for the
+ direct mapping of node identity to a physical machine. It was stored
+ this way in the PLC database as well.</para>
+
+ <para>As the design of the database progressed, the PlanetLab software
+ needed to identify nodes not by any one aspect of the physical machine,
+ but by a more generic identifier (as this identifier needed to be used
+ internally to refer to other aspects of a node, like which site it is
+ at) - what has been called a node id. Although better in some respects,
+ there are still drawbacks. For example, deleting a node entry from the
+ database and recreating a similar one could result in a new node id,
+ when nothing on the node itself really has changed. These problems are
+ primarily due to a lack of policy being documented, and instead, the
+ implementation details defining the policy.</para>
+
+ <para>Currently, when a node requests a script from the boot server as
+ the last step of the boot cd operation, it sends to PLC the output of
+ the program 'ifconfig' (among other data), which contains the network
+ settings the machine was configured with. From the network settings, the
+ primary MAC address is extracted by PLC and used to check the database
+ if the node exists. Here, the MAC address is used to look up a
+ corresponding numeric node id, which is used internally. The MAC address
+ and the node id are tied - if a new MAC address is used, a new node id
+ will be generated. If the node does exist, an appropriate script is sent
+ in response, based on the current node state. Again, this was fine, as
+ long as a node was identified correctly.</para>
+ </section>
+
+ <section>
+ <title>Node Authentication</title>
+
+ <para>What does a node (or PI, for that matter) have to do to prove that
+ it is one of the real, or legitimate, PlanetLab nodes? At first, this
+ was not an issue because the nodes were added to the system by
+ administrators, and all communication paths led only from PLC to the
+ nodes. Everything was downloaded from PLC, including information about
+ what experimenters can use the system, what packages to install for
+ updates. For this, a node only needed to send enough information in the
+ request to identify itself with PLC. From the PLC point of view, it did
+ not matter which node downloaded the packages for a node, so long as the
+ node was identified correctly and received the packages it was supposed
+ to. This was acceptable since the node was added to PLC by hand, thus it
+ was already 'authenticated'. During this period, a number of assumptions
+ were made:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>That a rogue node with the same network settings would not be
+ a problem, as the site technical contacts could prevent or detect
+ that</para>
+ </listitem>
+
+ <listitem>
+ <para>The ability to check to ensure a particular node was already
+ authenticated was not done (aside from assuring that the host's
+ public ssh key fingerprint did not change from one login to the
+ next)</para>
+ </listitem>
+ </orderedlist>
+
+ <para>As more previously manual steps became automated, a number of
+ situations came up in which a node would need to initiate and perform
+ some operation at PLC. There is only a small set of these operations,
+ and are limited to items such as, adding a node to the system (under a
+ previously authorized subnet), changing the 'boot state' (a record of if
+ the machine is being installed, or is in a debug mode) of a node, or,
+ uploading the logs of an installation.</para>
+
+ <para>To handle this new node authentication, a 32 byte random nonce
+ value was generated and sent to PLC during node boot time (at the same
+ time the network settings are sent). The nonce value in the PLC database
+ for that particular node is updated if the node is identified correctly,
+ and is used for authenticating subsequent, node initiated operations.
+ Then, for example, when a node install finished, a node could request
+ it's state updated, and all it would need to do would be to resend its
+ network settings, and the original nonce for authentication. If the
+ nonce in the database matched what was sent, then the requested
+ operation was performed.</para>
+
+ <para>The problem here is obvious: now, any node that can be identified
+ is essentially automatically authenticated. For a node to be identified,
+ it has to be in the database, and, new nodes can be automatically added
+ on any authorized subnets without intervention of an administrator or
+ tech contact. With this system, it is trivial to add a rogue node to the
+ system, even at a different site that was not originally authorized,
+ because the whole system is based on what a node sends PLC, which is
+ trivial to spoof.</para>
+ </section>
+ </section>
+
+ <section>
+ <title>Recommendations</title>
+
+ <section>
+ <title>How PLC Will Identify Nodes</title>
+
+ <para>Before any suggestions on what to change regarding the node
+ identity policy can me made, the question, what makes a node a node,
+ should be answered. This primarily depends on who is asking. From an
+ administrators point of view, a node could be tied to a particular
+ installation of the software. Reinstall the node, and it becomes a new
+ node with a new identity. However, from an end user's perspective, the
+ machine still has the same network address and hostname, and their
+ software simply was removed. For them, changing the node identity in
+ this situation does not make any sense, and usually causes them
+ unnecessary work, as they have to re-add that machine to their
+ experiment (because, as far as the PLC database is concerned, the node
+ never existed before then). This question is particularly import for
+ several reasons:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>It gives users a way to identify it, in order to use it for
+ their research</para>
+ </listitem>
+
+ <listitem>
+ <para>The node identity could be used by other external systems, as
+ a universal identifier</para>
+ </listitem>
+ </orderedlist>
+
+ <para>The following recommendation is made for a new node identity
+ policy. Rather that tie node identity to some attribute of the physical
+ machine, such as its hardware configuration as is currently, instead,
+ PLC will assign an arbitrary, unused identity to the node upon its
+ creation, and that identity will be stored locally at the node (most
+ likely on an external medium like floppy disk). Then as long as that
+ identity is still on the node, any hardware or software changes will not
+ necessarily require a change of the node identity. This will then allow
+ PLC, if necessary in the future, to change the node identity policy as
+ needed.</para>
+
+ <para>The following policy will apply to this new node identity:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>In the past, a tech contact was able to change the network
+ settings on a node automatically by updating the network
+ configuration floppy. Now, these changes will have to be done at PLC
+ (with the option of assigning a new node identity). Thus, the node's
+ network settings (excluding MAC address), are tied to the
+ identity.</para>
+ </listitem>
+
+ <listitem>
+ <para>Attempting to move the node identity to another machine will
+ halt that machine from being used by researchers until the change is
+ dealt with by either a PLC administrator or a site technical
+ contact. If approved, the node would reconfigure itself
+ appropriately.</para>
+ </listitem>
+
+ <listitem>
+ <para>A node identity cannot be reused after the node has been
+ deleted from the PLC database.</para>
+ </listitem>
+
+ <listitem>
+ <para>The node identity will not change across software reinstalls,
+ changes of the harddisks or network adapters (as long as the network
+ settings remain), or any other hardware changes.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Given the current design of the PLC database, there is still a
+ need to use, at least internally, a numeric based node identifier. Other
+ software and APIs available to researchers also use this identifier, so
+ the question becomes whether or not the above policy can be applied to
+ it without significantly changing either the PLC software or the
+ researcher's experiments. Answering this question is beyond the scope of
+ this document, and is left as implementation decision.</para>
+ </section>
+
+ <section>
+ <title>Authenticating Node Identity</title>
+
+ <para>It is clear that the previous model for authentication will need
+ to change, which assumes with identity comes authorization, to one where
+ a node can present its identity, then authenticate it as a separate step
+ in order to become authorized. During the boot process, a node can still
+ send sufficient information to identify itself, but, a new system is
+ required to prove that what it sends in fact does come from the node,
+ and not someone attempting to impersonate the node. This is especially
+ important as node identities are made public knowledge.</para>
+
+ <para>Authentication in distributed systems is a fairly widely
+ researched problem, and the goal here is not to build a new mechanism
+ from scratch, but rather to identify an existing method that can be used
+ to fulfill our requirements. Our requirements are fairly simple, and
+ include:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>The ability to trace the origin of a node added to PlanetLab,
+ including the party responsible for the addition.</para>
+ </listitem>
+
+ <listitem>
+ <para>Authenticating requests initiated by nodes to change
+ information at PLC. These requests involve little actual
+ communication between the nodes and PLC, and the overhead for
+ authenticating each request is small given the number and frequency
+ of them. This also means the need to open an authenticated channel
+ for multiple requests will not be necessary.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Given the public nature of PlanetLab, the need to encrypt data
+ during these system processes to prevent other parties from seeing it is
+ not necessary (also, simply hiding the details of the authentication
+ process is not a valid security model). Assuring the requests are not
+ modified during transmission is necessary, however. A public/private key
+ pair system could be used, where each site would be responsible for
+ generating a private key, and signing their node's identity. PLC could
+ then have a list of all public keys, and could validate the identities.
+ However, this is not recommended for several reasons:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>It places an additional burden on the site to generate and
+ keep secure these private keys. Having a private key for each node
+ would be unreasonable, so one key would be used for all nodes at a
+ particular site.</para>
+ </listitem>
+
+ <listitem>
+ <para>By using one key for all nodes, it not only increases the cost
+ of a compromised key (all identities would have to be resigned),
+ but, use of the key to add unauthorized nodes could not as easily be
+ detected.</para>
+ </listitem>
+
+ <listitem>
+ <para>Differences in versions of the software used to generate keys
+ would have to be handling, increasing the complexity of supporting a
+ system at PLC</para>
+ </listitem>
+ </orderedlist>
+
+ <para>To fulfill the above requirements for node identity, the
+ recommendation is made to use a message authenticate system using hash
+ functions and shared secrets such as in <citation>2</citation>. In such
+ a system, the shared secret (or refered to as key, but not in the
+ public/private key pair sense), is as simple as a fixed size, random
+ generated number. Of primary importance in such a system is the control
+ and distribution of the key.</para>
+
+ <para>Securing a key at PLC is relatively straight forward. Only a
+ limited number of administrators have direct access to the PLC database,
+ so keys can be stored there with relative confidence, provided access to
+ the PLC machines is secure. Should any of these keys be compromised, all
+ keys would need to be regenerated and redistributed, so security here is
+ highly important.</para>
+
+ <para>However, securing the secret on the client side, at the node, is
+ more difficult. The key could be placed on some removable media that
+ will not be erased, such as a floppy disk or a small usb based disk, but
+ mechanisms must be in place to prevent the key from being read by anyone
+ except the boot manager and the boot cd processes, and not by any users
+ of the machine. In a situation like this, physical security is a
+ problem. Anyone who could get access to the machine can easily copy that
+ key and use it elsewhere. One possible solution to such a problem is to
+ instead make the key a combination of two different values, one stored
+ on the floppy disk, the other being a value that is only known to the
+ PI, and must be entered by hand for each message authentication. Then,
+ in order to compromise the entire key, not only must the attacker have
+ physical access to the machine, but would have to know the other half of
+ the key, which would not be recorded anywhere except in the PLC
+ database. This ultimately cannot work because of the need for human
+ intervention each time a node needs to be authenticated.</para>
+
+ <para>Ultimately, the best solution for the circumstances here is to
+ leave the entire key on the disk; leave physical security to the
+ individual sites; and put checks in place to attempt to identify if the
+ key is being reused elsewhere. As before, the post-boot manager system
+ (running the real PlanetLab kernel), can be configured to prevent the
+ floppy disk from being read by any logged in user (local or not).</para>
+
+ <para>If the key was identified as being reused elsewhere, appropriate
+ actions would include deleting the key from the PLC database
+ (effectively halting any use of it), and notifying the technical
+ contacts and PIs at the site. If necessary, they could regenerate a new
+ keys after corrective actions had been taken.</para>
+ </section>
+
+ <section>
+ <title>Adding New Nodes</title>
+
+ <para>It is important to have control over the process for which nodes
+ are added to the PlanetLab system, and to be able to derive which party
+ is responsible for that machine at any point in the future. This is
+ because several different parties come to PLC for the list of nodes, and
+ PLC needs to provide a list that only includes nodes that have been
+ authorized. For one, the researchers who are looking to run experiments
+ need to identify a set of PlanetLab machines. Two, non-PlanetLab related
+ people who may have traffic related concerns or complaints, and are
+ trying to track down who is responsible for a node and/or the
+ researcher's experiment.</para>
+
+ <para>It is possible to envision at least several scenarios where having
+ a non-authorized node in the PLC database would be a problem. One of
+ which would be a researcher inadvertently using a rogue node (those who
+ installed it could easily have root access) to run an experiment, and,
+ that experiment being compromised across all of PlanetLab, or the
+ results from their research being tampered with. Another could include a
+ rogue node being used for malicious purposes, such as a spam relay, and
+ the (initial) blame being directed at PLC, simply because of the
+ association.</para>
+
+ <para>As shown previously, simply authorizing an entire network is
+ insufficient, as the ability to identify who authorized an individual
+ node on that subnet is unknown. Having the PlanetLab administrators add
+ all nodes by hand incorporates too much overhead, given the number of
+ nodes and the current growth of PlanetLab. This also places the
+ administrators in a state where they may not have the contact
+ information for the responsible party. A decent compromise will be to
+ require either the PIs or technical contacts at each site to enter in
+ their own nodes using the existing PLC interfaces. Given that one of the
+ existing steps for bringing a node online involves generating a
+ floppy-based network configuration file on the PlanetLab website, this
+ process can be extended to also add record of the nodes with little
+ additional impact to PIs and tech contacts. At this point, the per-node
+ shared secret and a node identity necessary for node authentication
+ would be generated and saved at PLC as well.</para>
+ </section>
+
+ <section>
+ <title>How To Remove Nodes</title>
+
+ <para>There may be the need for an administrator, PI, or technical
+ contact to remove a node from the system. This can be done simply by
+ removing the node record from the PLC database, thereby preventing it
+ from successfully authenticating at boot time. In addition, a node could
+ be effectively disabled (but not removed), by deleting the private key
+ for that node from the database. Once restarted, it would not be able to
+ come back online until a new key is generated.</para>
+ </section>
+
+ <section>
+ <title>Node Installation</title>
+
+ <para>The node installer shall be integrated into the Boot Manager,
+ rather than continue to be a standalone component. This will allow the
+ boot manager, when appropriate, to invoke the installer directly.</para>
+ </section>
+ </section>
+
+ <section>
+ <title>Conclusion</title>
+
+ <para>As outlined above, this new system effectively encapsulates a new
+ policy for node identity, and a new mechanism for verifying the node
+ identity and authenticating node-initiated PLC changes. In total, the boot
+ manager collectively will consist of:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>A set of interfaces at PLC that are used to perform
+ authenticated, node-initiated changes.</para>
+ </listitem>
+
+ <listitem>
+ <para>A set of interfaces at PLC that are used to add new nodes to the
+ system.</para>
+ </listitem>
+
+ <listitem>
+ <para>A package downloaded by the boot cd at every boot, which used to
+ install nodes, update configurations, or boot nodes, using the
+ interfaces above.</para>
+ </listitem>
+
+ <listitem>
+ <para>The policy for identifying nodes, and when that identity should
+ change.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Given the above recommendations, the boot strap process and the
+ chain of trust for adding a new node now exists as detailed below. A site,
+ a principle investigator, and a tech contact are assumed to be already
+ present, and authorized.</para>
+
+ <orderedlist>
+ <listitem>
+ <para>The technical contact downloads a boot cd for the new node.
+ Since the HTTPS certificate for the public web server is signed by a
+ trusted third party, the image can be verified by either ensuring it
+ was downloaded via HTTPS, or by downloading the PlanetLab public key
+ and verifying a signed copy of the cd, also available on the
+ website.</para>
+ </listitem>
+
+ <listitem>
+ <para>The now validated boot cd contains the CA certificate for the
+ boot server, so any host initiated communication that is using this
+ certificate on the cd can be sure that the server is in fact the
+ PlanetLab boot server.</para>
+ </listitem>
+
+ <listitem>
+ <para>The PI logs into their account on the PlanetLab website, also
+ over HTTPS and verifying the SSL certificates. Once logged in, they
+ use a tool to generate a configuration file for the new node, which
+ includes the network settings and node identity. During this
+ configuration file generation, record of the nodes existence is
+ entered into PLC, and a random, shared secret is generated for this
+ machine. The shared secret is saved in the PLC database, and is also
+ included in this configuration file.</para>
+ </listitem>
+
+ <listitem>
+ <para>Both the cd and the new configuration file (on a floppy disk),
+ are inserted into the machine. The machine is configured such that it
+ always starts off the cd, and never the floppy disk or the machines
+ hard disks.</para>
+ </listitem>
+
+ <listitem>
+ <para>After the boot cd finishes bringing the machine online, loading
+ all hardware and network settings from the floppy, it contacts the
+ boot server using HTTPS and the certificate on the cd, and downloads
+ and executes the boot manager.</para>
+ </listitem>
+
+ <listitem>
+ <para>The boot manager then contacts PLC to get the current state of
+ the node it is currently running on.</para>
+ </listitem>
+
+ <listitem>
+ <para>Based on this state, the boot manager can either continue
+ booting the node (if already installed), install the machine if
+ necessary, or take any other action as appropriate. Since this is a
+ new machine, the installation will be initiated.</para>
+ </listitem>
+
+ <listitem>
+ <para>After successful installation, the boot manager needs to change
+ the state of the node such that the next time it starts, it will
+ instead continue the normal boot process. The boot manager contacts
+ PLC and requests a change of node state. This request consists of the
+ node identity, data pertaining to the request itself, and a message
+ authentication code based on the shared secret from the floppy disk
+ and the request data.</para>
+ </listitem>
+
+ <listitem>
+ <para>The boot manager, in order to authenticate the request,
+ generates its own message authentication code based on the submitted
+ data and its own copy of the shared secret. If the message
+ authenticate codes match, then the requested action is performed and
+ the boot manager notified of success.</para>
+ </listitem>
+
+ <listitem>
+ <para>If the node is already installed, and no actions are necessary,
+ the machine is booted. To protect the shared secret on the floppy disk
+ from users of the machine, the kernel during runtime cannot access the
+ floppy disk. At this point, control of the system is removed from the
+ boot manager and run-time software takes control.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>Any action the boot manager may need to take that requires some
+ value to be changed in PLC can use the steps outlined in 8 through 10. As
+ an extra precaution to prevent unauthorized nodes from booting, the
+ process in step 7 should also use the authentication steps in 8 through
+ 10.</para>
+
+ <para>Given that the shared secret on the floppy disk can only be accessed
+ in the cd environment (when the boot manager is running and the boot cd
+ kernel provides floppy disk access), any operation that a node can perform
+ that results in a change in data at PLC must be performed during this
+ stage. During runtime, a node can still present its identity to PLC to
+ receive node-specific packages or configuration files, but all interfaces
+ that provide these packages or files cannot change any record or data at
+ PLC.</para>
+ </section>
+
+ <bibliography>
+ <biblioentry>
+ <abbrev>1</abbrev>
+
+ <title><ulink
+ url="http://rhlinux.redhat.com/anaconda">Anaconda</ulink></title>
+ </biblioentry>
+
+ <biblioentry>
+ <abbrev>2</abbrev>
+
+ <title>Message Authentication using Hash Functions - The HMAC
+ construction</title>
+
+ <authorgroup>
+ <author>
+ <firstname>Mihir</firstname>
+
+ <surname>Bellare</surname>
+ </author>
+
+ <author>
+ <firstname>Ran</firstname>
+
+ <surname>Canetti</surname>
+ </author>
+
+ <author>
+ <firstname>Hugo</firstname>
+
+ <surname>Krawczyk</surname>
+ </author>
+ </authorgroup>
+
+ <date>Spring 1996</date>
+ </biblioentry>
+ </bibliography>
+</article>
\ No newline at end of file
git://git.onelab.eu / bootmanager.git / commitdiff