OldGPGReferencesDevelopment: dev_SecurityPrototype.txt

File dev_SecurityPrototype.txt, 4.6 KB (added by peter.stickney@bbn.com, 13 years ago)

Security Prototype

1A Prototype of the GENI Authorization Architecture.
3Tom Anderson, Lujo Bauer, Arvind Krishnamurthy and Mike Reiter.
7The project's goal is to design, implement, and demonstrate a
8prototype authorization service for GENI.  GENI's scale, widespread
9deployment, and visibility will make it an inviting target for attack,
10and thus careful attention must be paid to security in its design. In
11our view, security considerations need to permeate every interface to
12be defined for GENI, and thus it is particularly important to build a
13prototype implementation to validate GENI's security architecture
14prior to construction funding.
16The GENI distributed services working group has identified several
17requirements for GENI's security architecture: least privilege,
18flexibility revocation, auditability, and scalability.  Unfortunately,
19none of the existing technologies address all of these requirements.
20For one thing, GENI's predecessors in both the distributed systems
21community (PlanetLab) and the Grid community (Globus) have primitive
22security architectures (key-based access control lists) that address
23authentication more than authorization. Some of these limitations are
24addressed by newer standards, such as Taos, SPKI/SDSI, PolicyMaker,
25and KeyNote, but implementations are scarce and none exist for the
26sorts of resources managed in distributed testbeds. Hence there is a
27need for a prototyping effort that will explore issues arising out of
28the use of fine-grained authorization in planetary-scale systems.
30Clearly, achieving all of these objectives is a multi-year task. For
31this one-year prototyping effort, we narrow our focus to the central
32element of the proposed GENI security architecture: fine-grained
33distributed authorization and access control. We seek to develop a
34prototype design and implementation for access control that is
35sufficiently rich and flexible that it could be applied ubiquitously
36in GENI to regulate access to virtually any resource.  We will deploy
37this prototype on PlanetLab, and demonstrate it using user programs
38that are executed in restricted environments, such as a Java Virtual
39Machine.  Users would build distributed applications/experiments in
40Java, which we would then ship around to PlanetLab nodes running our
41resource monitors.  The resource monitor would be used to first
42authorize the execution of the user program on a given node and then
43be used to enforce access restrictions to objects such as files and
44network devices during program execution.  By restricting ourselves to
45Java programs, we are leveraging the existence of a virtual machine
46that has the appropriate hooks for invoking access control checks.
47Note that the eventual implementation of GENI should include these
48hooks inside the OS kernel or a virtual machine monitor (such as Xen)
49in order to invoke the appropriate runtime checks.  Incorporating such
50hooks into the OS kernel or a VMM is more of an engineering issue and
51is not central to our technical efforts.
53Specific milestones
566th Month Deliverable (Feb '07):
58Demonstrate the technical feasibility of the authorization service.
59Project tasks include:
61a) Defining the structure of credentials and their concrete
64b) Implementation of APIs and libraries for creating cryptographic
65keys; for creating credentials; for creating proofs of policy
66compliance from a formal statement of an access policy and a set of
67credentials; and for verifying a claimed proof of a given policy (the
68resource monitor).
70c) Adaptation of access-control logics to encode access-control
71constructs and policies typical of those needed for GENI.
73Develop a demonstration that showcases all of the above system
74components.  Allow users to initiate experiments on PlanetLab nodes
75and have them be executed under the supervision of resource monitors.
76In particular, demonstrate the following features:
78a) Fine-grained control over access:  For example, for experiments
79   deployed by novice users, limit the programs to talking only to
80   other PlanetLab nodes.
82b) Fast startup and efficient execution.  Demonstrate that the new
83   features do not come at the cost of noticeable execution overheads.
84   Allow experimenters to instantiate slices and deploy experiments,
85   all in real time.
8712th Month Deliverable (Aug '07):
89Develop proof-of-concept tools that illustrate that the authorization
90service can support the various administrative tasks currently being
91performed by PlanetLab Central and site administrators.  Address
92scalability issues and release the reference implementations.
93Demonstrate the ability to track down the effects of a compromised
94administrator key and revoking privileges that have been incorrectly