A Tale of Two Federations

1. A Tale of Two Federations Jeff Chase Duke University

2. Reading the slides GENI users Test Tube Guy and Dr. D, and some of their credentials A A generic principal IdP.studentT IdP.facultyD A coordination service implementing some clearinghouse function, such as a Slice Authority AM SA Indicates trust of one principal in another, often associated with some kind of formal agreement: Indicates a request Aggregate Indicates credential flow

3. GENI trust structure: overview (v1.0) Users and tools Users create global slices and request aggregates to bind local resources to those slices. GENI Federation Oversight Bidirectional trust based onagreements AM AM AM AM CH Principals are users and organizations, and tools or servers acting on their behalf.

4. GENI trust structure: overview (v2.0) GENI “clearinghouse” • Each of these entities may: • Speak with its own keypair. • Wield credentials. • There are limited trust relationships among them. • Trust reflects agreements, and is limited by their scope. • Credentials capture this trust. • Trust may be transitive. GOC IdP GMOC PA SA I&M AMs trust the coordination services, transitively. AM AM Nothing has really changed, but we have named some of the CH coordination services, and introduced a federation root (GOC) to endorse federation-affiliated services. See the intro slide deck.

5. Coordination services • We consider three CH coordination services. • IdP: Identity Portal/Provider Register user identities and issue user credentials. • PA: Project Authority Approve projects and issue project credentials. • SA: Slice Authority Approve slices and issue slice credentials. GOC IdP PA SA Note: these coordination services are limited to identity management and authorization. There will likely be others, e.g., for resource control. We’ll also call coordination services coordinators for short. The intro slide deck explains these services and their roles.

6. A Tale of Two Federations GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M AM AM AM AM • Suppose, in the future, GENI wants to federate with, say, FIRE. • What are the alternatives? • What are the tradeoffs?

7. Option 1: indirect delegations GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M • The various coordinators can talk to each other to share information and validate one another’s users, projects, slices… • If there is no common trust management framework, then this might be the only way to go. • But it is brittle, inflexible, and labor-intensive.

8. Option 2: root federation GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M • Simple, easy. (Just a few rules in ABAC logic.) • Given suitable policies that allow such transitive delegations, federations will accept each other’s users, slices, projects, AMs. • Drawback: “one size fits all or nothing”. • E.g., AMs cannot easily choose to opt out.

9. Option 3: selective federation (a) GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M • In this example, FIRE accepts users from GENI. • A FIRE user may delegate rights for a slice or project to a GENI user, to the extent that per-project or per-slice policies allow it. • Of course it works the other way too: GENI could accept users from FIRE just as easily.

10. Option 3: selective federation (b) GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M • In this example, FIRE accepts users and projects from GENI. • A FIRE user may delegate rights for a slice or project to a GENI user, to the extent that per-project or per-slice policies allow it. • And a GENI project could create FIRE slices. • Of course it works the other way too….

11. Option 3: selective federation (c) GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M • In this example, FIRE accepts GENI users, projects, and slices. • …a GENI project could create FIRE slices, and a GENI slice could allocate resources at FIRE aggregates. • Other variations are possible. For example, FIRE could allow GENI slices on its aggregates, but disallow GENI users from creating FIRE slices or operating on FIRE slices.

12. Option 4: aggregates choose (a) GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M AM • This option offers aggregates more control. • In fact, aggregates may join a federation without the other’s knowledge or consent (even if the AMs promise to be faithful).

13. Option 4: aggregates choose (b) GOC FIROC IdP GMOC PA FirIdP GMOC FirPA SA I&M FirSA I&M • An AM may choose whose users, projects, and/or slices to accept. • In fact, aggregates can accept users, projects, slices without the federation’s knowledge or endorsement. • This will happen. Some aggregates won’t care about projects, slice credentials, and all that GENI stuff. (Think about EC2.) AM

14. The view from an AM • To an aggregate, the world is (has) a cloud of coordinators that the aggregate might choose to accept, or not. • EC2 only cares about VISA and MasterCard. AM

15. The view from an AM • Some coordinators are part of a federation, which is just a convenient grouping of services for an AM to accept as a bundle. • The AM may even accept them without joining the federation. AM

16. Joining a federation • The federation might place some trust in the AM as well, e.g., to treat users and their slices properly and report events. • The AM must join the federation and enter into an agreement. • The federation endorses the AM and advertises it to users. AM

17. The limits of federation power • But a federation cannot use the authorization framework to enforce its trust in an AM. • A federation can make everyone promise to be faithful, but it can’t prevent anyone from interacting beyond the scope of their agreements with the federation. GOC • A federation can give its members and partners a basis for deciding whether to trust one another. • But it can’t stop its users from going to any AM they want, and it can’t stop unaffiliated AMs from allocating resources to “its” users and slices. • It’s an accountability problem: authorization won’t help. AM

18. The limits of federation power Not to belabor the point, but let’s be sure we’re clear on this. Create sliver for slice s • Suppose TTG requests a createSliver on an AM that has not entered into any agreement with GOC, and is not endorsed by GOC. AM • There is nothing that can be done to stop this rogue AM from creating a sliver and “saying” it is part of the slice s (or not). • We can only deny this phishing AM the credentials it needs to convince others to believe it and encourage users to use it. • The good news is that we can rely on “good” AMs to check compliance with coordinator policies. It doesn’t make us any less safe: compliance is “voluntary” no matter who checks it. But we can hold the “good” AMs accountable.

19. AM-centric view of coordination • So, in general, the AMs are always in control. They choose their own policies, and any surrender of sovereignty to a Federation is voluntary, or induced by socio-political factors outside the trust structure. • Therefore, we should design coordinators that leave AMs free to choose from the menu of services available. • To the extent that AMs choose the same coordinators, they should work. AM

20. Multi-federation? AM AM AM AM An aggregate might choose to affiliate with multiple federations.

21. Multi-federation To the extent that AMs overlap in the coordination services they affiliate with, those services should work to coordinate them… …even if the aggregate’s affiliation is not exclusive. AM AM AM

22. Multi-federation Federations may merge or split. There might be multiple instances of each kind of service within a federation. AM AM AM AM To the extent that AMs affiliate with shared coordination services, those services should work to coordinate those AMs.

23. Declarative trust management • Every picture in this slide deck is a trust graph. • The vertices are principals. • The edges represent trust: directed delegation of partial trust from one principal to another. • We can specify all of these trust structures rigorously using a delegation logic. • We can implement and deploy them using an off-the-shelf PKI-based trust management framework. • ISI libabac for RT0 role-based trust logic (“ABAC”) • Deploy new authorization policies and trust structures without changing the code. • Evolve them according to events at the socio-political layer.