GENI Clearinghouse Panel

1. GENI Clearinghouse Panel GEC 12 Nov. 2, 2011 INSERT PROJECT REVIEW DATE

2. Setting Some Definitions First • Aggregate Authority • is responsible for the management of an aggregate, but can delegate selected functions to other actors. The aggregate authority is the only one who can enter into agreements for the aggregate • Identity Portal • is a trusted (i.e., one that has signed an agreement with the clearinghouse) system that issues GENI credentials for experimenters. • Identity Provider • is a service providing authentication of potential GENI actors • Slice Authority • is a system that issues credentials for slices. INSERT PROJECT REVIEW DATE

3. More Definitions • Clearinghouse • is both an entity and a system consisting of software, operations, and policy to broker trust between federation partners. • GENI Project • is a grouping of experimenters and slices working on a common effort. It may have multiple slices concurrently and over time. • Project Leader • is the actor who is ultimately responsible for the behaviors of a GENI project. • GENI Oversight Group • is the proposed group responsible for ensuring that meta-operations and the clearinghouse operations groups fulfill their responsibilities. It is also the governance body for the GENI federation, responsible for guiding project direction and resolving disputes between other actors. INSERT PROJECT REVIEW DATE

4. Why should we have project leaders? • Responsibility: A “grown-up”, e.g. PI • What if there are IRB issues? • Want someone with some permanence who is easy to contact and find. • Want to know delegation is done responsibly. • We really don’t know all the experimenters • Not always technically possibly to determine most directly responsible party • We can determine a project leader, slice creator and anyone else who has changed the slice. • We don’t know who logged in via SSH to hosts in the slice and ran experiments though INSERT PROJECT REVIEW DATE

5. What does the Clearinghouse do? • First, it is a “legal” entity and trusted root. • Minimize the # of pairwise agreements • Set a common level of expectations in federation through a set of policies and agreements with CH • Asserts who has entered agreements and is in good standing (mechanism TBD) • Primary Services • Register project leaders and projects & bind them • CH.ProjLead(i)  Bob • Bind slices to projects verifying all actors in federation in good standing before “endorsing” a slice • If delegated ability to SAs, maybe SA_1.GENIProj(i)Slice_X • Identify “official” aggregates (ABAC or registry or both) • CH.EndorseAgg_X INSERT PROJECT REVIEW DATE

6. Secondary or Optional CH Services • A Component Registry • Resource Discovery • Attest to who has signed agreements • An Identity Portal • Backed by InCommon, issues GENI identity credentials • A Slice Authority • Slice Tracker (Is that standard nomenclature?) • Verify 3 kinds of resource allocation policy (From NSF, project size is accurate, or with federated partners) • Could be delegated to issuing SAs except for policies about aggregate GENI usage INSERT PROJECT REVIEW DATE

7. Projects Sizes & Approval Process • Do 3 sizes make sense? Do we even need them? • Small: less than 28 days, 1 slice at a time • Medium: semester (5 mo.), multiple slices • Large: Long term or more than 20% of a resource • Should committee approval be required for the large projects? • What kind of turn-around for approval is appropriate? • Small = real time • Medium = 2 business days • Large = 1 week INSERT PROJECT REVIEW DATE

8. Info to collect at project registration • When a Project Leader creates a new project, what should they enter? • How many simultaneous slices they expect • How long-lived the experiment will be • Co-project leaders? • Purpose of experiment(s) • Size of experiment’s load on shared resources like backbone links • other? INSERT PROJECT REVIEW DATE

9. Where to check federation level policies? • Type 1: NetSC Council makes general rule • Example: grad student slivers can get X hosts / slice • Are all of these things based on attributes that could be proven elsewhere, or do some need global view of ALL slices? • Type 2: Is project X still acting like it has size N? • This should be delegable to SAs to check • Type 3: Rule about GENI aggregate usage w/ another federation • Example: GENI can only use X% of link A to FIRE • Could be determined by the CH or their AM, but not any one SA. Is that always true? INSERT PROJECT REVIEW DATE

10. Do we need federation level policies? • Cost isn’t high if we are doing post-hoc verification and not inserting CH into every resource request • Need to have API to report back to “slice tracker” at CH • Or could report back to SAs maybe • We don’t want to discourage other federations from linking with us • We don’t want to discourage NSF from funding us  • Though unclear whether they will ever make such global policies (They may care more about their own aggregates, e.g. GENI racks or backbones) • Do we need to decide this now? INSERT PROJECT REVIEW DATE

11. GENI Oversight Group (GOG) • Who should make up representatives of such a group? • Should we create a federation charter to establish it? • A lot of the CH policy doc content could move there • GOG Responsibilities • Directing Clearinghouse, GMOC and Security Ops. • Resolve disputes between federation actors • Decide if someone is kicked out or let back in, hear appeals. INSERT PROJECT REVIEW DATE

12. Certificate Authority Policy • Do we need formal CA policies for anyone issuing credentials? • How do we protect key material • How is revocation handled • How long do credentials live • Who are approved Identity Portals & Providers? • What is are vetting requirements? NIST LOA ? • Etc • May have a small enough number of actors issuing principal credentials that we can avoid this for a while, right? INSERT PROJECT REVIEW DATE