Digital Object Architecture Giridhar Manepalli gmanepalli@cnri.reston.va.us Corporation for National Research Initiatives http://www.cnri.net/

Proposed GENI Services GENI Federated Clearinghouse Security Model GENI Experiment Management Service

GENI Federated Clearinghouse Spiral 1 Effort

? Resource Discovery Adapt in the Backend Cluster A Cluster B Discover & Access Discover & Access Interoperability Layer Adapt ? Cluster B Experimenter Cluster A Experimenter Discover & Access

GENI Federated Clearinghouse (GFC) Spiral 1: Defined a basic data model of the GFC Implemented a prototype of the GFC that federates records from ProtoGENI Prototype is made available at http://geni.doregistry.org/GFC/ Assumed that the GFC service was part of the control framework Spiral 2: Plan to integrate with other clusters and make the GFC operational Assuming that the GFC service is an experimental service not a core control framework component Goals To allow resource (and other entities) discovery across clusters To provide an interoperability layer between various existing clearinghouse models by defining a common mapping model To provide an open-source clearinghouse software that future, or existing, GENI communities can use

Aggregate Manager Identifier Data Model User Identifier Public Key or X509 Certificate Description HRN Contact Credentials Component Identifier Manager Description HRN Resource Identifier Resource Identifier Component RSpec Description Status Credentials Aggregate Manager Identifier HRN Identifier Description Component Identifier Aggregate Slice Sliver Identifier HRN Identifier Description Slice Authority User Identifier Credentials Owner or Not Status Sliver Slice Identifier HRN Identifier Description Expiration Status Resource Type Service Identifier Access Details Public Key or X509 Certificate Policies

GFC Homepage

Resource Search Results

Resource Record

Namespace 10510 10510.0 (GPO) 10510.1 (TIED) 10510.3 (ProtoGENI) … 10510.3.0 (Sandbox) 10510.3.1 (University of Utah Node) 10510.3.2 (University of Wisconsin Node) 10510.3.n … 10510.3.4 (University of Washington Node) 10510.3.3 (University of Kentucky Node) For example, University of Wisconsin component identifier: 10510.3.2/2f61b3fe-22cb-102c-a837-00304868a4be-r-c7300-32-c Issued/Used by ProtoGENI Clearinghouse

GENI Federated Clearinghouse (GFC) Scalability GFC Client 1. Which Handle Server do I ask for handle 10510.3.1/456? Global Handle Registry 2. Ask Handle Server"1" User Record for 10510.3.1/456 HRN Description Contact Public Key or X509 Certificate Credentials 6. User Record 3. Resolve 10510.3.1/456 Handle Record for 10510.3.1/456 Registry Information Type of Record: "User" Stored or not 4. Handle Record 5. Resolve User 10510.3.1/456 GENI Federated Clearinghouse (GFC) Organization A Organization N GFC Mirror Handle Server "X" Handle Server “1" GFC Mirror

Security Model Spiral 1 Effort

Security: PKI Public Key Infrastructure, an effective and standards-based solution, allows for secure processing of identity claims Issues Trust is assumed to be transitive, e.g., trusting certificate authorities (CA) implies trusting end users Managing trust stores and revocation lists is manual and ad hoc Every server part of a common service, e.g., GENI service, needs to be explicitly synchronized among each other to be effective Resolution Need explicit “trust” management mechanism Need dynamic, synchronized, and distributed management of trust stores

Proposed Security Model Trusted user claim False claim by an intruder 1. Claims to be 10510.3.1/456 GENI Service A GENI Service B 1. Falsely Claims to be 10510.3.2/789 3. Issues PKI Challenge 3. Issues PKI Challenge 4. Successfully Responds 2. Trusts 10510.3.1/* & Retrieves Public Key 4. Fails the Challenge 2. Trusts 10510.3.2/* & Retrieves Public Key Organization X 10510.3.1/* GENI Trusted Handle Services Organization Y 10510.3.2/* Un-trusted user claim Revoked user claim 2. Trusts 10510.3.2/* but fails to find the record 1. Falsely Claims to be 10510.3.2/abc 1. Claims to be abc/123 GENI Service D GENI Service C 2. Does Not Trust abc/* & Denies the Claim 3. Denies the Claim

Proposed Security Model Complete details of the proposed model is available here: http://groups.geni.net/geni/attachment/wiki/DigitalObjectRegistry/ClearinghouseSecurityReqmnts.pdf The model allows users to claim their identifiers (handles) explicitly or implicitly using certificates The model requires trusting the Handle System caBIG, a Grid application based on the Globus Toolkit (Grid middleware), verified and experimented with the Handle System successfully for service end-point authentication CHI project, another Grid application using the Globus Toolkit, is currently using/experimenting with the Handle System for identifying metadata records and access controls Frank Siebenlist, from Argonne National Laboratory, is the POC for the Handle System effort in those two projects

Spiral 1 Integration Issues GFC Other than ProtoGENI, no other cluster participated in the federation Possible reasons: Supporting the GFC to be a core control framework component may be orthogonal to the clusters’ goals Clusters have, or soon will have, their own clearinghouses serving the users (so why support another clearinghouse) Security Model Unexplored by GENI members, so it’s still an unknown entity

Spiral 2 Integration Plan GFC Restate the role of the GFC as an experimental service Consequently, the GFC does not affect the clusters’ approach to clearinghouses Security Model Push the model details to the OMIS group and get it evaluated Work with the OMIS group to integrate with other clusters

GENI Experiment Management Service (GEMS) Spiral 2 Effort

Experiment Management Experiments have, and result in, various resources which are related to each other (e.g. specs, logs, software, etc.) Packaging those resources together (logically) is important while archiving, in order to reuse, repurpose, or reanalyze Those resources, however, exist on multiple platforms and environments Solution: A unified service that establishes the relationship between various resources and that integrates with heterogeneous repositories would meet these requirements

GENI Experiment Management Service Experiment ID 1 Experiment ID 2 Access Layer Specification ID X Specification ID X Graph of Related Documents I need to know about Experiment with ID 1. Regular User Source code ID Y Source code ID Y Graph of S/W Dependencies Logs/Results ID A Logs/Results ID B Graph of Related Logs ExperimentRelationship Graph Experiment Relationship Graph Experiment Relationship Definition Layer Here are the logs. Tool Logs Source Code Experimenter Here is the source code. Repository Infrastructure Trac File System/ Amazon S3 Digital Object Repository Subversion Administrator

Spiral 2 Integration Plan Host an Experiment Repository for GENI members Done! Develop a prototype demonstrating the GEMS capability Work with both the Experiment and OMIS working groups to define an interface for the GENI Experiment Management Service, involving experimenters from various clusters