- GENISecurity Project Status Report
GENISecurity Project Status Report
I. Major accomplishments
Definition of a set of services and requirements comprising an initial version of the security specification for GENI control frameworks.
A. Milestones achieved
Posting of the first draft of the GENI Security Architecture, GENI-SEC-ARCH-0.3 and a minor revision GENI-SEC-ARCH-0.4. (Downloadable from http://groups.geni.net/geni/attachment/wiki/GENISecurity/GENI-SEC-ARCH-0.4.pdf )
B. Deliverables made
In addition to the GENI Security Architecture draft document, Stephen Schwab also attended GEC-4 and presented two briefings, one in the Control Framework WG session addressing security architecture topics for the various control frameworks, and one in the OMIS WG session addressing GENI Operational Security issues.
II. Description of work performed during last quarter
A. Activities and findings
There were two main activities pursued over the past reporting period and several minor activities. The main activities were the drafting of the GENI Security Architecture and the presentation and discussion of that security architecture as well as more general security issues with attendees at the GEC-4 conference in Miami. Among the minor activities of note were a series of discussions with the GENI Meta-Operations Center (GMOC) staff regarding how data would be collected and accessed within that project, and what the consequences would be for labeling the data, determining access rights, and ultimately enforcing controls on who can access what data.
Our first draft of a GENI Security Architecture was well received, and drew a fair number of comments which we have addressed or will attempt to address in the next revision of the document. We focused on issues of identity, authentication and authorization/access control because these are the central building block issues that immediately present themselves across four of the five control frameworks. (We note that the ORBIT control framework did not initially face many authorization or access control decisions because of the approach to let a GENI research authenticate and use an entire wireless testbed. However, as soon as ORBIT introduces mechanisms to limit wireless testbed nodes to specific spectrum allocations, this control framework will face similar problems of granting authorization rights to the spectrum resource and enforcing access to this resource.)
Among the concerns regarding the security approach are those of complexity and of not addressing other security issues that are of concern to various projects. Regarding the complexity of distributed authorization and credential passing schemes, we had discussions with Harry Mussman of the GPO at GEC-4, and will follow up on his concerns. There is also a thread of discussion regarding how clearinghouses fit into the control frameworks, and some of those discussions intersect with security issues – perhaps the most important is to ensure that whatever clearinghouse functions are deployed are non-bypassable. This is a somewhat challenging idea to enforce in a distributed systems where the resource providers can sometimes provide services legitimately outside the scope of a clearinghouse – nevertheless, the GENI system needs to support the right architecture – and especially the right security mechanisms – so that whatever policy is declared at a clearinghouse can be verified and enforced throughout the control frameworks.
The other major set of security issues to address are those that are relevant to many of the projects building on or integrating with the control frameworks, but which may not be directly addressed by the set of initial security mechanisms outlined as being applicable to the control frameworks. We will be selectively investigating GENI prototypes, such as Million-node GENI, where a new concept (desktop VMs, for example) that is outside of the initial slice-based facility architecture, is central. Hopefully we will be able to survey a few GENI spiral 1 projects and from this set extrapolate to additional security mechanisms that might be added to the round out the security architecture and make a start on addressing the security needs that are both near-term and not covered by the security mechanisms tailored to the control frameworks.
B. Project participants
The following SPARTA staff are participating in the GSAT project:
Stephen Schwab, Alefiya Hussain. In addition, we also consult with Jim Horning, Sandra Murphy, and Calvin Ko, although their participation is constrained by the limited amount of funding.
C. Publications (individual and organizational)
D. Outreach activities
We have been actively collaborating with Rob Ricci/Utah and other members of the projects collaborating under the ProtoGENI cluster umbrella. This collaboration includes periodic bi-weekly status telecons as well as additional frequent email and other interactions with Emulab staff at Utah. The aim of this effort is to track mechanisms being introduced within Emulab to support ProtoGENI multi-site deployment and prototyping, and to capture the security-relevant aspects of these mechanisms within our security abstractions.
We also have been working closely with John Wroclawski and Ted Faber of USC/ISI under the DETER GENI cluster. In particular, we have discussed Attribute Based Access Control (ABAC), sharing papers and exchanging ideas on how ABAC might serve as a useful basis for the security abstractions underpinning the DETER Federation implementation as it evolves to support GENI-specific goals. We have released the ABAC software to DETER/TIED project staff under terms of the GENI Public License, and have a request to similarly provide the ABAC software to the ORCA project to prototype and investigate integration within their framework. We aim to capture the security architecture impacts gleaned from this work within the GENI Security Architecture.
We have also continued to interact with Larry Peterson and the PlanetLab control framework, as well as had discussions with Max Ott and others collaborating on the ORBIT testbed. Additional discussions with Jon-Paul Herron and the GMOC project at Indiana University have also taken place, with an aim of working out how to control access to measurement data collected and accessed via the GMOC.
F. Other Contributions
Converted submitted file by Julia Taylor (firstname.lastname@example.org). Original file can be found here