1 / 29

GEC5 Security Summary

This document discusses the GENI security architecture, clusters, authentication, and authorization diagrams, including call-outs for other notable projects. It provides an overview of the security plans and status of GENI clusters and projects.

weaverpaul
Download Presentation

GEC5 Security Summary

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GEC5Security Summary Stephen Schwab Cobham Analytical Services July 21, 2009

  2. Outline • GENI Security Architecture – plans • GENI Clusters & Projects – status chart • GENI Clusters – identity/authentication & authorization diagrams • GENI Security call-outs for other notable projects

  3. GENI Security Architecture • Revised Document Posted on GENI wiki • Includes “As-built” discussions on each control framework • At least one more revision in August

  4. Security Chart

  5. PlanetLab • Cluster B

  6. Identifiers • GID consists of • UUID generated as per RFC4122 v4 • HRN (resolvable nicknames) • A SSL X.509 Certificate with parent field • The GID stored in subject-alt-name of certificate • The authority that is responsible for the entity authenticates it by signing the certificate

  7. Authentication • Authentication is done on the basis of the certificate that is signed by the responsible authority. • Authentication implies no permission • the certificate just indicates identity

  8. Identity and Authentication 3a. Request a GID by sending 1024-bit RSA public key Planetlab Central 1. Generate self-signed certificate authority. The PlanetLab Consortium serves as top-level slice, GID 2. Register root certificate with registry Aggregate Manager Slice Manager Slice and User Registry 3. Register: PLC generates a certificate that includes a UUID (public key) and HRN in the subject-alt-name field. The subject-public-key contains the user public key. It signed by the PLC. 4. Register user with registry

  9. Authorization Based on credentials; credentials grants privileges to users

  10. Slice Creation Aggregate Manager GID Slice & User Registry 4. GetTicket: the ticket is defined by a 5-tuple, (GIDCaller, GIDObject, Attribs, Rspec, Delegate) . The GetTicket operation is completed by the AM 1. Verify user credentials and authorize him to perform slice creation PlanetLab Central Slice Authority 3. Request Ticket: User selects components, creates Rspec. If request is granted, the AM signs the request and returns a ticket Registries 2.List Resources: On behalf of the user, the SM calls each peer AM to learn of available resources. Resource Status Service 6. SM maintains a database of all slices created with the resources used. Storage Compute Cluster Component Manager 7 Start Sliver: User requests sliver to be brought to running state Measurement 5. Redeem Ticket: User redeems the ticket causing the sliver to be created. The Rspec defines the resources bound to the slice. Network

  11. ProtoGENI • Cluster C

  12. Identifiers • GID consists of • UUID (ex: a0f4) • HRN (resolvable nicknames) • A SSL Certificate • The GID stored in DN of SSL certificate • Cert issued by home emulab that authenticates entity in GENI • DN also includes email address

  13. Authentication Authentication is done on basis of the SSL certificate that is signed by the home emulab Authentication implies no permission, SSL certificate just indicates identity

  14. Identity and Authentication Slice & User Registry 3a. Request a GID by sending hashed public key 1. Generate self-signed certificate authority, serves as root for Emulab. ProtoGENISlice Authority GID 2. Register root certificate with clearing house ClearingHouse 3. Register: MA generates a certificate that includes a UUID (public key) and HRN in the DN field. 4. Register user with Clearing house Resource Status Service

  15. Authorization Based on credentials; credentials grants privileges to users

  16. Slice Creation Compute Cluster Storage Measurement Aggregate Manager Network GID Slice & User Registry 1. GetCredential: S A issues self credential authenticating user to perform actions 2. CreateSlice: User creates a new slice and receives a credential granting control over the slice 5. DiscoverResources: User submits credentials and send request to each AM for detail resource lists (Rspecs) Home Facility 6. RequestTicket: User selects components, creates Rspec. If request is granted, the AM signs the request and returns a ticket Slice Authority 7. RedeemTicket: User redeems the ticket causing the sliver to be created. ClearingHouse 8. StartSliver: Client requests sliver to be brought to running state Resource Status Service 4. ListComponents: Requests list of all AM registered with the CH 3. Register: SA registers the user and the slice 6b. AM sends copy of ticket to Slice Registry (who tracks resources in each slice).

  17. Orca/Ben • Cluster D

  18. Identifiers • GID consists of • RFC 4122-based GUIDS • Public Key • attributes

  19. Identity and Authentication User Registry 4. User request a GID by sending a public key via a browser interface Shibboleth Identity Provider 1. Identity provider maintains registry of all other id providers including their GUID, keys, and attributes GID 2. Runs as a SOAP server, all messages are digitally signed as per WS-Security 5. Returns a RFC 4122 based GUID and security attributes Principal Registry 3. Each ID provider is responsible for the principals it registers. It maintains a local MySQL database.

  20. Slice Creation GID 1. Researcher/guest starts experiment creation using a web browser. Authenticated by the ID provider (not shown) Service Manager/ Slice Manager Guest Handler (one per sliver) 2. CreateSlice / GetTicket: user request allowed if he has the appropriate attributes and endorsed by ID. 3. UpdateTicket: broker grants ticket to the service manager that can be now redeemed from the domain authority. Each guest has a guest handler within the service manager. The ticket includes resource type properties. Broker/ ClearingHouse Domain Authority/ Aggregate Manager Site Policy (one per resource pool Policy Module (applies attribs. from ID provider) 5. RedeemTicket: The ticket is now presented to the DA along with configuration properties for setup of slice. 0. Export Tickets: Delegate splitable tickets to broker. Attempts to honor all tickets issued by the broker 6. UpdateLease: The DA grants the service manager the resources as a lease. It includes the unit properties as assigned from the DA..

  21. DETER TIED • Cluster A

  22. Identifiers • ID are triples • Testbed , project, user ex: (“DETER”,”proj1”,”faber”) • Also defines federation IDs • 160-bit SHA-1 hash of the public key • Avoids collisions when federating • Triple name can use a fed-ID • (fedid:1234, “proj1”, “faber)

  23. Authentication Authentication is done on the basis of the home testbed using public-private key pairs

  24. Identity and Authentication Slice & User Registry TIED Federator/ Management Authority 1. Create a name and fed-ID for testbed 2. Register federated testbed with clearing house/federator ClearingHouse / Federator 3. Register: MA registers a new users with the testbed, associates him with a project, generates a fed-ID 4. Register user and fed-ID with Clearing house/federator Resource Status Service

  25. Authorization Based on attributes assigned to user; project group is a type of attribute Attributes grant privileges to users

  26. Experiment/Slice Creation Compute Cluster Storage Measurement Federator/ Slice Authority Network GID Slice & User Registry Slice & User Registry Slice & User Registry 1. User is authenticated by home facility aggregate manager for a federated exp. 2. User initiates a federated experiments 4. User submits a canonical experiment description to the federator Home Facility 5. Federator selects components, request resources from other testbeds. Federator/ Aggregate Manager 6. Once all the resources are granted the experiment configuration begins Federated Fedds Federated Fedds Federated Fedds 7. Grant the user complete control of the experiment Resource Status Service Resource Status Service Resource Status Service 3. Requests list of all testbed advertisements registered with the CH 4b. Register the user and the experiment with the CH 6b. Fedd sends a copy of CEDL to the CH (who tracks resources usage across GENI).

  27. Orbit • Cluster E • No diagrams yet • Spiral 2 plans on-track to introduce security mechanisms to address Spiral 2 needs

  28. Other Notable Projects • Enterprise GENI • Controller off-loads security mechanisms from individual deployed switches • Digital Object Registry • Provides for searching of identities beyond a single clearinghouse • Million Node GENI • Language-based VM: restricted python

  29. Questions • What mechanisms should GENI be using for identity and authentication? • What mechanisms should GENI be using for policy creation/definition/distribution and authorization? • Should GENI security focus on yet-to-be-implemented or already-up-and-running features?

More Related