1Parallel and Distributed Systems Group Courant Institute, New York University

DisCo: Middleware for Securely Deploying Decomposable Services in

Partly Trusted Environments

Eric Freudenthal and Vijay Karamcheti

Jordan Applebaum, Tracy Pesin, Lawrence Port, Edward Keenan, Hesham Hassan, Sean Holohan, Oliver Kennedy, Michelle Nabavian, Robert Schatz, Nick West, Kenji Yoshihira

2Context: Distributed deployment of Composable systems• Traditional

– Multi-tier deployments span systems within a trust domain– Communicate with agents authorized by known others.– Component permissions evaluated statically

• Future– Application components deployed as needed onto

systems administered by others– (consider “grid” systems, BPEL scripts, applets, WS)– Permissions computed dynamically, can change

3Problem: Infrastructure Designed for Traditional Scenario• While extensible systems support remote

deployment of agents and inter-host communication channels, they express inappropriate underlying assumptions– Static security configuration files– Authorize transactions rather than sustained relationships– Authorization ≠ authentication– Are clumsy frameworks for decentralized administration

• Advanced authorization tools are available– But poorly integrated with critical system services

4Example

• Many relationships require mutual authorization.

Ericproxy29

Proxy29Acme.installableProxy29

Times.pro

vider

Acme82 Times.proxyHost

Acme82

TimesSrvr

Eric Times.powerUser

TimesSrvr Times.provider

• Relationship between Acme & Times may be indirect

5Ideal solution provides…

• Expressive & continuous authorization for…– Configuration and maintenance of sandbox permeability– Secure communication channels– Agent deployment / Mutually anonymous logins– Authorized code delivery– Discovery of service providers

• However…Disconnect between needs and tools– Transitive trust management provides indirection

• However continuous authorization left as exercise

– SSL uses X.509– Sandbox permissions from static configuration files

7Problem 1: Inappropriate bundling of authorization• Secure network connections: TLS/SSL

– Authentication & cipher• PKI key-exchange, session cipher

– Authorization• X.509 & ACL• No mechanism to check or monitor for revocation• Doesn’t monitor for expiration!

– If some part is inappropriate• Must build everything from scratch

• Java code source authorization– TLS (X.509) authentication– Statically mapped to policy files that are

only read once

TLSport, certs, ACL, id

connections

8Problem 2:Inappropriate authorization abstraction• Generic access controller authorizes transactions`

Input

Policy

ID

Credentials

Output

Decision

• Maintenance of authorization (e.g. credential revocation) left as programming exercise• Boolean authorization

9DisCo approach 1: Monitoring within authorization system• Opaque universal authorizer abstraction

– Algorithm & policy opaque to program

• State of authorization automatically monitored– Timers, subscription to revocation services…– Call-back on change-of-authorization

Authorizer

(knows policy)

ID +Credentials

Monitor

(enforces policy)

callback when authorization changes or lostread authorization status

update credentials

optional: read or adjust authorization parameters

10DisCo Approach 2:Use modular authorization everywhere• Programs instantiate appropriate authorizer objects

– Monitoring & validation available to all authorization-sensitive components, as required– Policy and algorithms can be modularly replaced

• Used for– Logins, sandboxes– Code distribution– Communication channels (streams, RPC, …)– Discovery

11dRBAC: DisCo’s Authorization System

• distributed Role Based Access Control– Roles represent families of parameterized access rights – Each parameter represented by a named attribute– Attributes bound to an attenuating operator– Default value is full access, can be attenuated

• Support for decentralized authorization– Transitive delegations can span multiple admin domains– Built-in continuous monitoring of validity– Built-in discovery of delegation chains– Implementation: network-aware wallet at every node

12Switchboard: DisCo’s Modular Communication Stack

Modular Asynchronous

Object Transport

layer

send

deliver event

Stream MUX

RPC

Hydrant

Other Switchboard Components

Authorize

XPORT

Cipher

Liveness` Connectivity monitoring

Cipher (ID, secrecy…)

XPORT

Cipher

Liveness

TCP

Communication channel must provide• Reliable identity for home wallet• Data integrity• Indication if connectivity is lost• Mutual authorization of corresponents

Authorize` Authorization Authorization

13Extending Java’sSandboxing Mechanisms• Objects only instantiated if authorized

– Both publisher & agent requesting deployment/instantiation

• Sandbox membrane synthesized dynamically– From both agent (user) and code publisher– Derived from dRBAC’s valued attributes

• Class files distributed from networked “code safes”– Represent publishers, only distributed to authorized hosts– Can require delegation and need-to-know– Receiving host validates authenticity & authority

14Discovery of Service Providers & Deployment of Remote Agents• Discovery of referral to nearby node providing service

– System stores & validates only soft state• Every service has well known home, used if duplicates unavailable• Initial implementation: broadcast, fail over to home• Future version: DHT

– Integrity: Extend SDS model• Referrals include evidence of validity

• Activator establishes deployment “login”– Accepts requests from deployer, establishes sandbox– Deploying agent demonstrates authorization to activate

• Also provides “agent” sandbox authorization

– Receiving system demonstrates authorization to receive

activator

15

proxy29

Putting it together: DisCo in Action

acme82

secure classfile repository

TimesSrvr

1. connect to activator

2. create proxy to deploy

3. request activation

4. pickup code

5. install

6. proxy connects to TimesSvr

activator

16Evaluation: Case Studies

• Automated decomposition and deployment– Partitionable Services Framework

• Application components customized as needed– Interfaces expunged as needed using byte code rewriting

• Components installed using activator• Constructed by Anca Ivan (Also a current NYU grad)• Deployments optimized using AI planning techniques

• Manual decomposition, automatic deployment– Secure multi-resolution image distribution

• DisCo used to install proxies and GUI components

– Multi-player game and secure video distribution– Few lines of code related to security

17Evaluation: Performance

Monitored RPCLatency

TransportLatency

(normalized by serialization time)

18Related work

• Deployment environments– Grid: One level of indirection between communities– Spin, Java, WebOS: Extensibility– J2EE: composable deployment within domain– Jres: resource accounting for Java

• Communication– TLS, JXTA, Cactus, RMI

• Authorization– PKE, X.509: Authentication– Policymaker, SDSI/SPKI, OASIS: transitive trust– RTn: parametrized roles, credential discovery– Skiplists: scalable revocation lists

19Summary

DisCo Provides• Customizable secure communication channels• Automatic configuration of execution sandboxes• Discovery of service providers• Dynamic monitoring of authorizing relationships

Trust Management Subsystem: dRBAC• Continuous authorization (notification when lost)• Distributed implementation• Modulated roles

20

Thanks

(questions?)

21General Problem: Access Control

• Access control decisions– Locally defined policy– Agents: Biological or software entity– Boolean decision: Permission to perform restricted action

• Transitive Trust Management Systems– Policy has form of transitive delegations – Provide a natural solution

• Challenges for complex and decentralized systems– Access control decisions consistent with global state– Manageable administration

23dRBAC is a Trust Management Authorization Framework • Access privileges associated with named roles

– Times.user, Acme.installable, Times.proxyHost

• Role privileges transitively delegated via credentials[Eric→Times.powerUser] Times

• Authorization = chain from agent to privilege[CpusRUs.1M→Times.proxyHost ] Times

[Acme.host→CpusRUs.1M] CpusRUs

[Acme82→Acme.host] Acme

• Monotonic: adversary can not increase access by hiding information

24Scalability Challenges with Traditional TM

• Every access rights class require a distinct role• Trust should degrade transitively• Explosion in roles and delegations when large

number of organizations and trust relationships

• Example: Propagating multiple access levels

[Acme.host→CpusRUs.1M] CpusRUs

[Acme.economyHost→CpusRUs.10k] CpusRUs

[Acme.host→Acme.economyHost] Acme

25dRBAC Solution: Valued Attributes

• Named roles represent a parameterized family of rights– Each parameter represented by a named attribute and an

associative monotonic operator– Delegations restrict parameters– New attenuated access rights classes easily introduced

• Example– [Times.user→Times.PowerUser {delay≥30}] Times– [Times.powerUser→Bbg.user {delay≥10}] Bbg

26Valued Attributes have Many Uses

• Access rights– Eric times.powerUser {duration ≤ 25}– Bank.teller Bank.authorize {withdraw ≤ 10,000}– NY.jrlicense NY.license {speed ≤ 45, passengers ≤ 2}

• Sandbox permissionsProxy Host.install {vSize<15, priority≤0.8, storage ≤ 3}

• QoS:Aol.member Times.user {delay += 30}

• System remains monotonic

trial membership

28Distributed Implementation of dRBAC

Objective• Local policy, global authorization

Requirements• Permit efficient decentralized administration• Consistent view of distributed credential repository

• Discovery and validation of authorizing credential chains• Revocation of authorization if credentials invalidated

• Support for continuous authorization– Including premature revocation

29dRBAC Solution: Network of Credential Wallets

Wallets: Authorizationconsistent with global state

– Distributed, horizontally partitioned database

• Validation: wallets represent local authority– Represent owner to other wallets (delegs. stored w/issuer)– Trusted by local access controllers for authorization

• Discovery of needed delegations– Participate in directed automated search– Monotonicity permits optimization

• Skip branches violating attribute constraints

[C B.b']B pub/invalprove

discover

auth lost

network

33Switchboard

• Modular secure & reliable communication stack

Modular Asynchronous

Object Transport

layer

send

deliver event

Stream MUX

RPC

Hydrant

Switchboard Adapters

XPORT

Cipher

Liveness Connectivity monitoring

Cipher (ID, secrecy…)

XPORT

Cipher

Liveness

TCP

Communication channel must provide• Reliable identity for home wallet• Data integrity• Indication if connectivity is lost• Monitoring of correspondent’s authorization

Auth Authorization Auth

35Generalizing dRBAC

• Observation– In organizations, co-endorsement increases belief– More agents must err to improperly enable access

• However, scalability challenge in (Boolean) TM– Enumerate combinations eligible for increased access– Result:

• Explosion in number of delegations or• Reduction in granularity of access decisions

• Alternative approach: QTM– Probabilistic quantification agent reliability– Bayesian composition and aggregation

36A Different Interpretation of Multiplicative Valued Attributes in dRBAC

[ Tim → Times.reporter { integrity *= 0.9 } ] Times– Interpretation: Tim has the “integrity” characteristic of a

Times reporter with probability 0.9.

– Delegation “enabled” by boolean “chance” variable vt

“The Post” has similar roles (trusted by “The Times”)– Modeled by variables vp and vpt respectively:

Tim Timesreporter

E(vt) = .9

vp vptPaul Timesreporter

.9 .8 .72

Postreporter

٨ =

vp ٨ vpt

37QTM: Stochastic approach to redundant authorization• Benefit

– Representation of independent co-endorsement

• Recall from previous slide:– Tim: – Paul: ٨

• Times’ confidence in an event reported by both:

1 – ( (1-E(vt)) * (1- (E(vp) * E(vpt)) ) = 0.97

P(Paul lied)P(Tim lied)

.9

.9 .8

report beliefE(vt) = .9

E(vp) = .9 E(vpt) =

0.8

.9

.9.8 .72

.9

.97

٧

٧

38Propagation of Administrative Independence• Problem: Some agents may be “coupled”

– Married couples, reporters hired by the same manager– Link spamming

• Solution: Common link limits combined reliability

MikeClara

Curtendorsementtimes .9

.9

.9

.89.9 .99٨ =

Mike Clara

Curttimes

.9 .9

.9

.96

.81

.81Mel.9 ٧

٧

.9.9 .9.9

٨ ٨٧

.9.9

٨٧

.9

39Evaluating Stochastic Authorization

• Reduce to bounded monotonic SSAT problem– No negation – DAG of “chance variables” and Boolean operators

• Compute or approximate expected value– General problem is P-Space hard– Many problems are small enough to enumerate– Monte Carlo simulation for larger problems

• Prohibitively expensive if small error required• Investigating hybrid approaches

– Enumerate common cases to reduce “unknown” region– Monte Carlo trials of others

40Related Work

• Others have also investigated– Co-endorsement authentication

• Disjoint Paths: Reiter and Stubblebine• Web-of-trust: Zimmerman• Non-monotonic systems: Beth, Borcherding, and Klein. • Stochastic framework: Maurer

– Markov variant: Richardson, Agrawal, Domingos

– Discovery & Parameterized authorization• RTN : Li & Winsborough

• Built upon DisCo: Deployment Planning System– Partitionable Services Framework– Anca Ivan (NYU, Graduating Ph. D.)– provides security & translation among namespaces

41Summary and Future work

• QTM and dRBAC: local policy, global decisions– Representation and propagation of partial authorization

• Simplifies policies, increases scalability, Bayesian framework

– Infrastructure provides coherent local views• Continuous authorization, discovery of authorizing credentials

• Future directions– Stochastic Trust

• Detection of weak or limiting links • Multiple stochastic attributes

– dRBAC• Decentralized validation services, possibly using skip lists (Goodrich)• Representation of richer monotonic ontologies

– Incorporation into other systems (P2P, WS…)

42

Fin