D u k e S y s t e m s Some Issues for Control Framework Security GEC7 Jeff Chase Duke University

GENI Distributed Services Preliminary Requirements and Design Tom Anderson and Amin Vahdat (co-chairs) David Andersen, Mic Bowman, Frans Kaashoek, Arvind Krishnamurthy, Yoshi Kohno, Rick McGeer, Vivek Pai, Mark Segal, Mike Reiter, Mothy Roscoe, Ion Stoica Flashback to 7/10/07

Security Architecture What is the threat model? What are the goals/requirements? Access control Authentication and key management Auditing Operator/administrative interfaces Flashback to 7/10/07

Threat model Exploitation of a slice –Runaway experiments ä Unwanted Internet traffic ä Exhausting disk space –Misuse of experimental service by end users ä E.g., to traffic in illegal content –Corruption of a slice ä Via theft of experimenter’s credentials or compromise of slice software Exploitation of GENI itself –Compromise of host O/S –DoS or compromise of GENI management infr Flashback to 7/10/07

Requirements: Do no harm Explicit delegations of authority –Node owner  GMC  Researcher  students  … Least privilege –Goes a long way toward confining rogue activities Revocation –Keys and systems will be compromised Auditability Scalability/Performance Autonomy/Federation/Policy Neutrality –Control ultimately rests with node owners, can delegate selected rights to GMC Flashback to 7/10/07

“Authorization Example (simplified)” 1) Delegate: all authority 2) You can authorize X to send to GENI nodes University 1 Local admin University 2 3) You can authorize X to send to GENI nodes Student GENI Management Central Slivers Resource monitor 4) You can authorize X to send to GENI nodes 5) You can authorize X to send to GENI nodes send X says send? Machine X Flashback to 7/10/07

Where are we now? SFA is “rough consensus and running code”. SFA outlines some suggested security mechanisms and policies. Still needed: security architecture – Common across CFs – Separates policy from mechanism – Sufficiently powerful for future policy needs – Plays well with others – Uses standard solutions when suitable – SFA isn’t any of that.

GENI Security Architecture Agreement on underlying mechanisms: – Endorsement of identity – Assertion of attributes – Delegation of rights – Anchored in some set of trust roots Issued by whom? How are are the subjects named? What are the attributes, rights, etc.? How to broker trust? How are authorization policies specified? Lots of discussion (shepherded by Steve Schwab) SFA is not the right starting point or guide to consider these questions.

External Identity Providers in GENI (?) GENI should enable/permit external IdPs. – Leverage powerful identity solutions developed by the large community focused on that problem. – Free GENI participants from administering identities and accounts. Which IdPs? Shibboleth and perhaps others. – Shibboleth is mature and widely deployed by universities and other institutions. Single Sign On (SSO) SFA appears to preclude IdPs: just one reason why we need to move beyond SFA.

Using IdPs An IdP is just a trust anchor maintained by an institution. The IdP authenticates the user agent (login). IdP asserts attributes of the user identity. – E.g., signed assertion of attributes of identity bound to an HTTPS session. – Might not reveal identity: e.g., just “Duke student”. Authorization policy in the server can consider these attributes (e.g., ABAC). – “Duke students may use this facility on Monday.”

IdentityProvider(IdP) Service Provide r Directory 1. I’d like access 2. Please login to your home IdP, which I trust. 3. I’d like to login for SP. Use r 4. Login 5. Here are your session attributes to send to SP. 6. Here are my attributes. 8a. Access granted 8b. Access Denied Policy SSO 101 (e.g., Shibboleth)

Operators ORCA Servers (Actors) Broker (CH) ticket redeem lease Authority/AM delegate Slice Manager (SM) request XML – RPC Example: ORCA CF Java Web portal For GENI the ORCA SMs are hosted at institutions. Web portal Web portal Users and “hands-free” tools

The Point of the Example Each CF server has a Web portal interface. – (at least in ORCA) We can use external IdPs to authenticate users at the portals. BUT, if server SM invokes AM or CH, how does AM/CH know the user’s attributes? – Shibboleth defines “delegated authentication” mechanisms for this case. Easy if (user agent == browser) – “Hands-free” tools are a different problem.

Shibboleth in GENI, IMHO Easy to use to authenticate user/browser at a portal “at the edge”. Once authenticated, user can upload a public key for use by “hands-free” tools. – Standard for existing testbeds and clouds – Leverages external IdPs and avoids PKI Continue to use GENI key-based mechanisms internally. Continue to explore potential of delegated authentication, but do not depend on it.

Related Security Issues Semantics/constraints for delegation of tickets. – Specification and broker splitting: not embraced by SFA Authorization for “interesting” aggregates – OpenFlow – Cyberphysical (“don’t point the camera at the sun”) – Not addressed by SFA Location of policy decision/enforcement code – Policy code does not have to run at the component or AM! Naming structures – If A asserts attributes of object X, is it possible for M to hijack the name X, i.e., to hijack the endorsement? – SFA specifies (in essence) DNSSEC hierarchy with zones.

eom

Guest/experiment Slice Manager (SM) RENCI/GENI clearinghouse Broker Engine tickets Exchange of labels, tokens, configuration attributes etc. through SM. leases Multiple aggregate managers (AM) Stitching