D u k e S y s t e m s

A Tale of Two Federations

Jeff ChaseDuke University

IdP.facultyD

SA

Reading the slides

IdP.studentT

GENI users Test Tube Guy and Dr. D, and some of their credentials

A coordination service implementing some clearinghouse function, such as a Slice Authority

Indicates trust of one principal in another, often associated with some kind of formal agreement:

Indicates a request

Indicates credential flow

A A generic principal

AMAggregate

Bidirectionaltrust based on

agreements

GENI Federation Oversight

GENI trust structure: overview (v1.0)

CH

AM AM AM AM

Users and tools

Principals are users and organizations, and tools or servers acting on their behalf.

Users create global slices and request aggregates to bind local resources to those slices.

GENI trust structure: overview (v2.0)

AM AM

GOC

• 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.

GMOC I&M IdP PA SA

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.

AMs trust the coordination

services, transitively.

GENI “clearinghouse”

Coordination services

GOC

• 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.

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.

AM AM

GOC

GMOC I&M IdP PA SA

AM AM

FIROC

GMOC I&M FirIdP FirPA FirSA

A Tale of Two Federations

• Suppose, in the future, GENI wants to federate with, say, FIRE.

• What are the alternatives?

• What are the tradeoffs?

GOC

GMOC I&M IdP PA SA

FIROC

GMOC I&M FirIdP FirPA FirSA

Option 1: indirect delegations

• 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.

GOC

GMOC I&M IdP PA SA

FIROC

GMOC I&M FirIdP FirPA FirSA

Option 2: root federation

• 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.

GOC

GMOC I&M IdP PA SA

FIROC

GMOC I&M FirIdP FirPA FirSA

Option 3: selective federation (a)

• 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.

GOC

GMOC I&M IdP PA SA

FIROC

GMOC I&M FirIdP FirPA FirSA

Option 3: selective federation (b)

• 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….

GOC

GMOC I&M IdP PA SA

FIROC

GMOC I&M FirIdP FirPA FirSA

Option 3: selective federation (c)

• 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.

GOC

GMOC I&M IdP PA SA

AM

FIROC

GMOC I&M FirIdP FirPA FirSA

Option 4: aggregates choose (a)

• 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).

GOC

GMOC I&M IdP PA SA

AM

FIROC

GMOC I&M FirIdP FirPA FirSA

Option 4: aggregates choose (b)

• 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.)

The view from an AM

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.

The view from an AM

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.

Joining a federation

AM

• 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.

The limits of federation power

AM

• 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.

The limits of federation power

Not to belabor the point, but let’s be sure we’re clear on this.

• Suppose TTG requests a createSliver on an AM that has not entered into any agreement with GOC, and is not endorsed by GOC.

AMCreate

sliver for slice s

• 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.

AM-centric view of coordination

AMSo, 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.

Multi-federation?

AM AM AM AM

An aggregate might choose to affiliate with multiple federations.

Multi-federation

AM AM AM

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.

Multi-federation

AM AM AM AM

Federations may merge or split. There might be multiple instances of each kind of service within a federation.

To the extent that AMs affiliate with shared coordination services, those services should work to coordinate those AMs.

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.