Agile Management of Dynamic Collaboration

Agile Management ofDynamic Collaboration John Mitchell Patrick Lincoln Stanford University SRI International David Dill, Li Gong, Mary Baker Ninghui Li Dynamic Coalitions PI Meeting

Contract Start date: 5/4/2000 Duration: 48 months (12 mo optn) Agent POC Steve Spendlove SPAWAR Personnel Stanford John Mitchell (PI) Mary Baker, David Dill (Faculty) Ninghui Li (Researcher) Graduate Students SRI Patrick Lincoln (co-PI) Drew Dean Vitaly Shmatikov Consultant Li Gong (Sun/JavaSoft) Project Organization New additions!

Goal • Trust and security for dynamic coalitions • Decentralized authentication and trust decisions • Dynamic policy determined by coalition member policies • Policy language, deduction engine, examples • Secure adaptive networking • Key management, discovery, search and delivery for secure peer-to-peer communication; wireless • Coalition peer-to-peer services • Sites may offer to provide services • Clients search for services • Some services may be established using mobile code • Service-oriented infrastructure based on secure communication protocols, decentralized trust management

Trust management Emerging approach for distributed infrastructure Based on keys, policies, inference engine No standard off-the-shelf implementation Jini Dynamic service search and configuration Based on Java, RMI Limited Java security Protocols Secure multicast, P2P require key management Decentralized routing flawed (e.g., AODV, BGP) Security, reliability require careful design and analysis Peer-to-peer Napster: centralized Gnutella, Freenet: decentralized Inefficient n2 search No security Background

Trust management Role-based TM language Inference engine, impl Comparison with other access formalism Jini architecture Secure architecture Code filter Protocols Discover errors … Predicate abstraction Verify AODV, contract sign without finite bounds Decidable protocol case Peer-to-peer Evaluate systems coalition discovery, search network simulation Mobile People System Map names to device addr Track addr changes over time Progress Summary (since 1/01) Collaboration: Drew Dean (Xerox), Jon Millen (SRI), Will Winsborough (NAI)

Talk Outline • Year 1 Accomplishments • Report deliverables and publications • Trust Management • Role-based policy language, demo systems • Protocol analysis • Methods and applications • Distributed services • Decentralized name server, distributed timestamps

Report Deliverables • Technical report sections documenting • Trust-management approach to policy analysis and negotiation for dynamic coalitions • A Jini-based system for dynamic discovery, query, and selection of services and community members in a highly dynamic environment • Mobile-code security mechanisms adapted to a Jini environment.

Sample Publications (Year 1) • Trust Management • A state-transition model of trust management and access control, CSFW 2001. • Nonmonotonicity, User Interfaces, and Risk Assessment in Certificate Revocation, FC 2001. • Mobile code security • Mobile code security by Java bytecode instrumentation, DISCEX II 2001. • Protocol analysis • Successive Approximation of Abstract Transition Relations, LICS 2001. • Coalition services and peer-to-peer systems • Mitigating Routing Misbehavior in Mobile Ad Hoc Networks, Mobicom 2000. • Building Trusted Distributed Services Across Administrative Domains (unpublished).

Remainder of presentation • Trust management • Example • Outline of RBTM language • Demo summary • Protocol analysis • Predicate abstraction • Sample application • Distributed services • Decentralized name server, distributed timestamps

Distributed Policy Example Coalition Member A • Staff  Baugh, Giaccia • Give • A.General. • BattleDamageAssessor • read access to • SatelliteImagery(HiRes) Coalition Member B • General Hanson • Coalition_files(A)  • General.Coalition_files(A) • Give A.Staff • read access to Coalition_files(A) Hanson • BattleDamageAssessor  Jones • Assistant  … • Coalition_files(A)  Plan.ppt, map.jpg • Coalition_files(A)  Assistant.Coalition_files(A)

Credential Chains Root CA Conference Registration Stanford is accred university Regular $1000 Academic $500 Student $100 Stanford Mitchell is regular faculty Registration message Faculty can ident students Mitchell Certification Root signs:Stanford is accred university Stanford signs: Mitchell is regular faculty Faculty can ident students Mitchell signs: Chander is my student Chander is my student Chander

Hierarchical naming (SDSI) • Names, keys, and namespaces • A name denotes a principal or group • Each principal has one or more keys • Each principal may define own names • Write A.B for A’s definition of B • Specification of groups • A.B  C A’s group B contains C • A.B  C.D A’s group B contains C’s group D • A.B  C.D.E A’s group B contains d.E, for every d  C.D

“Trivial” extension to roles • Name, key, namespace • A name denotes a set of principals (Role) • Principal may define own names roles • Write A.B for A’s name role B • Simplified logic of roles • A.B  C A’s role B contains C • A.B  C.D A’s role B contains C’s role D • A.B  C.D.E A’s role B contains d.E, for every d  C.D

Example • Friends and Family • Alice. Friend  Bob • Alice. Friend  Carol • Bob. Friend  Ted • Bob. Friend  Alice • Alice. Friend  Alice. Friend. Friend • Role defined by this policy • Alice. Friend = {Bob, Carol, Ted, Alice}

Graph algorithm [Li, Winsb…, M] • Build graph based on policy • Keep table for local name at local site • Propagate keys along links • Digitally sign credentials when leaving local site Alice. Friend  Bob.Friend Bob Alice Friend Friend Ted Bob Alice Carol

Enhanced Policy Language RT1 • Relations between entities • Manager(x), Physician(y), FileOwner(z) • Permissions over resource groups • Read(reconnaissance_maps) • Threshold structures • Allow access if two guards grant access • Quantification over entities (subtle) • Read(?f)  Supervisor(Owner(?f)) Supervisor can read subordinate’s file Intermediate language: reducible to Datalog, poly-time

Calendar Demo (Thursday PM)

Calendar Policy • Concepts • Time categories • Time slot identified by hour of day and day of week • Time slots grouped into overlapping categories • Activity categories • Same names as time categories • Read permission • Principal or group given read permission for category • Only read appt for activity category, regardless of time • Write permission • Principal or group given priority for a category • Appointment with highest priority takes precedence

Part of Tony Soprano’s policy Roles Tony.Crew  Chris Moltisanti, Paulie Walnuts Tony.Boss  Jackie Aprile Tony.Wife  Carmela Tony.Children  Anthony Jr. , Meadow Tony.Family_Members  Tony.Mother, Tony.Wife, Tony.Children Tony.Read(Work)  Tony.Boss Tony.Read(Family)  Tony.Wife Tony.Schedule(Work,Important)  Tony.Crew Tony.Schedule(Work,Most important)  Tony.Boss Tony.Schedule(Family,Very important)  Tony.Family_Members Tony.Schedule(Family,Most important)  Tony.Wife Tony.Schedule(Personal,Very important)  Tony.Wife Read Write

Future Demo (under construction) • Web-based storage and file sharing • Users can upload, download files • User policy determines file access • Policy concepts • Locker owner determines upload capabilities, download policy • File owner can determine read, write • Extensions: version control, application support passwd

Site design Client cert? Key generation on browser Registration, server signature Install browser certificate https SSL with client authentication Create space Visit space Modify policy Enter name for shared space Policy Manager Upload files Download files

Formal Verification Techniques • Model checking has had a real impact on system design • Explicit-state protocol verifiers (Spin, Murphi) • BDD-based symbolic model checking for hardware design (SMV, VIS, FormalCheck, Rulebase, etc.) • Advantage: Automation reduces user effort to a feasible level • Limitation: Models must be finite-state. • Interactive theorem proving • Systems: ACL2, HOL, Isabelle, PVS, STeP • Practical impact on floating point algorithms (Intel & AMD) • Advantage: generality. E.g., can verify systems with unbounded state spaces, or families of systems. • Limitation: Labor-intensive.

The Wedge of Formal Verification Need a dial to tune up or down accuracy of analysis Value to Design Verify Abstract Invisible FM Refute Effort Invested

Conservative abstraction If abstract system satisfies safety property, so does concrete system   Abstraction Function  Concrete system Abstract system  Goal: use abstraction to reduce infinite system to finite state

Abstraction with refinement Predicates f1, f2,...fN OK Abstract Transition System (finite-state) Model Checker Approximate Predicate Abstractor Concrete Transition System (refine) Counter-example Trace

Abuse-free contract signing protocol • Protocol proposed by Garay, Jakobsson and MacKenzie, CRYPTO ’99. • Protocol has two participants (signers) and a trusted third party who mediates in case of disputes • Protocol is supposed to guarantee fairness • Fairness means that a honest participant can not be cheated (“fairness” is a safety property!) • Shmatikov & Mitchell (1999) discovered a flaw where unfairness could result, using finite-state model checking • We checked corrected protocol using predicate abstract for arbitrary numbers of simultaneous contract signings • The revised protocol was proved fair

Mobile people (example decentralized service) • People move between applications, devices, roles • Desktop, laptop, PDA, cell phone, pager, hotel phone • Why do they do this? • One device does not serve all purposes • Changes in job, organizations • Previous mobility work • “anywhere/anytime” connectivity to a single device • Our motivation • People are the true endpoints of much communication • Similar issues if “role” is intended endpoint

Decomposition of Problem • Mobile People Architecture • On what device do I reach a mobile person in a timely manner? • IdentiScape • How do I name mobile people as endpoints, rather than their devices? work email home email work phone pager home phone cell phone work email work phone ICQ home phone Dan Jane

IdentiScape goals • Easily name people online • Map name to • Contact information for people • Could be personal proxy information for extra privacy • Other stuff people want • Reduce information management problems • Name reuse issues • Name change issues • Name robustness issues Service avoids individual update of individual address books

Naming problems • Name reuse • Defunct pizza parlor phone # reassigned to Jane • Jane gets lots of pizza orders • Name changes • Email from Jane’s lawyers goes to old address • Old address controlled by party she’s now suing • Name robustness • Your address/number is too similar to someone else’s

IdentiScape solution • Naming service(s) • Allow callers to use one identifier to reach a person • Provide robustness of names • Directory services (identity object services) • Enable people to control the contents and accessibility of their own online identity information • Separation of naming and directory • Scalability • Trust

IdentiScape Architecture IdentiScape service 1 • jane • dan • supervisor Sender 2 3 4 Identity object Jane’s contact information Query “jane@IdentiScape.nom” 1 Return: address of identity object 2 Query identity object 3 Return: contact information 4

History service • Authenticated list of name transitions • Signed by name holder and name services • We assume a public key infrastructure • “Persistence” and control over old names • You’ll reach me with my old name if you run it through history service • Nobody else can prove they used that name at that time • Name space manager cannot retract existence of old name

1990 1996 1998 mgb@ucb.edu 1994 mgb@stanford.edu Example use of history service • 1990 - mgb gets a name from UCB • 1994 - mgb gets a name from Stanford • 1996 - Berkeley removes mgb name • 1994 - name change inserted • 1998 - another mgb gets a name from UCB • 2050 - Query: Current (mgb@ucb.edu, 1992) ?? Response: mgb@stanford.edu Implementation uses cryptographic timestamping method

Failure • Does not make the problem go away • Provides insight used to solve problem eventually Prefer the term “Challenge” Grand Teton Disappointment Peak

Project Challenges (“Failures” as req) • Management • SRI team too small initially • Jini • Jini is not as successful “out there” as it could be • Jini protocols are over/under specified • Mobile Code Security • Code filter is good general tool • Have not produced convincing application of tool • Distributed policy management • Problem is P-complete: will design for “expected case” Failure = learn by trying

Trust management Role-based TM language Inference engine, impl Comparison with other access formalism Continue demos, design distributed policy service Jini architecture Secure architecture Code filter Apply to calendar demo Protocols Discover errors … Predicate abstraction Verify without finite bounds Decidable protocol case Key mgmt, coalition security Peer-to-peer Evaluate systems coalition discovery, search network simulation Mobile People Decentralized coalition services Progress Summary Collaboration: Jonathan Smith (Penn), Jon Millen (SRI), Will Winsborough (NAI)

Agile Management of Dynamic Collaboration