wiki:CompSec-QSR-1Q2012

Version 1 (modified by Adam Slagell, 7 years ago) (diff)

--

CompSec Project Status Report

Period: (GEC 12 -GEC13]

I. Major accomplishments

A. Milestones achieved

We created the following documents

  1. GENI Clearinghouse Policy v. 0.4, 0.4.1, 0.4.2
  2. Clearinghouse Panel Summary from GEC 12

B. Deliverables made

  1. Took recommendations and notes from the clearinghouse panel and drafted a new clearinghouse document. Circulated for feedback on appropriate lists and updated it twice with minor revisions.
  2. Reviewed GENI rack design documents, participated in reviews for exoGENI and instaGENI, and provided recommendations to design teams.
  3. Checked LLR document and Aggregate Provider Agreement for necessary changes and determined none were needed at this time.
  4. Participated in discussions on authentication and authorization in GENI.
  5. Served as the LLR representative.
  6. Identified needed agreements and policies for GENI.
  7. Recommended considerations for privacy policies with regards to aggregate providers and opt-in users.

II. Description of work performed during last quarter

A. Activities and findings

The beginning of this period was spent digesting the comments from the clearinghouse panel and working with Jeff Chase on consensus towards the many concepts presented in it. It took a bit of time for everyone to agree that the concepts in the clearinghouse could be supported by the architecture and proposed ABAC logic. The clearinghouse document underwent one major revision, and two minor ones to reflect the changes in terminology that developed. Version 0.4.2 is the most current. There are still a few loose ends until a few remaining questions are answered related to whether or not there needs to be a global slice tracker at the clearinghouse and what its requirements are.

I participated in the reviews of the GENI racks and commented on their design documents. I focused on issues that could affect the ability to adhere to existing agreements and policies as well as provided a high-level sanity check on security design issues. After many back and forth discussions on email and phone calls, I made several recommendations to each team. I don't think either will have problems meeting requirements for attribution or such as stated in existing documents I have written, both draft and approved.

I reviewed existing documents for changes after altering the clearinghouse document, but I found no changes needed currently. I did identify the need for several new agreements in the near future. Most immediately I think we need a project leader agreement and Acceptable Use Policy for experimenters. I have noted what is needed in these in the existing clearinghouse document. Next, I believe a federation charter is needed for establishing governance, and this is a prerequisite for any changes to the incident response plan. Finally, agreements should be established with identity portals and slice authorities as they have several responsibilities alluded to in the clearinghouse document.

I participated in several discussions with regards to authentication and authorization with the goal of (1) making sure that what is proposed in the clearinghouse document can be realized, and (2) informing myself to make a recommendation regarding adoption of ABAC. Regarding the latter, I found ABAC to be an elegant solution to many of the problems of realizing the clearinghouse policy and other agreements and would recommend its use given two caveats. First, there should be default policies that could be used by most aggregates out of the box. Second, complexity should be abstracted away with good tools. I know that ISI has been working on GUI tools for the aggregate operators, but I have not evaluated these. But at no point should learning RT 2 be a prerequisite for running an experiment or configuring a standard aggregate in my opinion.

I also spent a bit of time digging into the potential privacy issues related to data collected from aggregates. I think I laid some of the foundation for developing a more formal policy and laid out the issues for the GPO. Of particular concern to me is the privacy of opt-in users, and I recommend that GENI push that responsibility off on to the experimenters. That can be spelled out in a future AUP.

Finally, I continued in my role as the GENI LLR representative.

B. Project participants

Adam Slagell

C. Publications (individual and organizational)

The only related publications are the documents I created as the deliverables, listed in Section A.

D. Outreach activities

There have no been substantial out reach activities beyond those already within the GENI community. Intra-GENI communication has been on the ABAC and Dev email lists, the monitoring calls and the exoGENI and instaGENI reviews.

E. Collaborations

None outside of normal GEC activities and discussions and phone calls with the GPO and other GENI projects.

F. Other Contributions

N/A