1 / 33

Agile Management of Dynamic Collaboration

Agile Management of Dynamic Collaboration. John Mitchell Patrick Lincoln Stanford University SRI International David Dill, Li Gong, Mary Baker Ninghui Li. Contract Start date: 5/4/2000 Duration: 48 months (12 mo optn) Agent POC

glorialee
Download Presentation

Agile Management of Dynamic Collaboration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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) Research scientists Consultant Li Gong (Sun/JavaSoft) Project Organization

  3. Goal • Trust and security for dynamic coalitions • Coalitions via peer-to-peer service concept • Sites may offer to provide services • Clients search for services • Service may be established using mobile code • Secure adaptive (wireless) networking • Key management, discovery, search and delivery for secure peer-to-peer communication • Decentralized authentication and trust decisions • Policy language and compliance checker • Service-oriented infrastructure based on secure communication protocols, decentralized trust management, and secure mobile code

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

  5. Jini architecture Code filter Architecture design Implementation of some parts in progress Peer-to-peer Evaluate current systems coalition discovery and search problems network simulation Trust management Comparison with other access control mechanisms Identify role-based TM Implementing inference engine Protocols (ad hoc wireless routing) Improve DSR reliability watchdog, pathrater Discover looping in AODV model checking, abstraction Collaboration: Drew Dean, Xerox New Personnel: Ninghui Li, Trust Management Mary Baker, Wireless Networking Collaboration: Jon Millen, SRI Progress Summary

  6. Jini-Based Service Architecture • Three phases for dynamic service installation • Request lookup server; receive lookup proxy code • Specify service via lookup proxy; receive service proxy code • Access service via downloaded service proxy Group Lookup Service Client lookup proxy service proxy Service Mobile code Problem: Standard Java-basedJini has limited security guarantees Approach:Develop protocols, trust mechanism, mobile code security Solutions useful for Jini and for other dynamic coalition platforms

  7. Mobile Code Security Asdfasdg./as sdfgsdfg gfsdfg s gfdsdfg sdfg sdfgdsdfgf Asdfasdg./as sdfgsdfg gfsdfg s gfdsdfg sdfg sdfgdsdfgf • Code transmitted and executed • E.g., transparent dynamic installation of user interface, communication protocol, device driver, Jini service proxy • Problem: Untrusted code executed inside mission-critical system • Approach:Dynamic code analysis, code monitoring, and load-time code modification to insert checks and controls

  8. Dynamic peer-service goals • Manage client risks • Authenticate or establish trust in service (solution:TM) • Contain mobile code risks (solution: code filter) • Manage service risks • Authenticate or establish trust in client (solution: TM) • Dynamic trust (solution:Trust Management) • Service has no prior knowledge of client • Client has no prior knowledge of service • Establish trust through signed statements by transitively known principals

  9. Disneyland Wireless device for Electronic cash Data communication Attraction UI Functions Store, communicate secure data Find trusted friends and family Control local devices Mobile reconnaissance team Ad hoc wireless networking Secure group communication Client obtains real-time data and control features from service Illustrative scenarios

  10. Jini Architecture • Lookup server stores credentials • Client, server consult TM • Client runs bytecode filter • Trust management is a service Client trusts service Lookup Service Service Client Trust Mgmt Service trusts client Client filters mobile code Lookup Service Lookup Service Service Client Filter Client Trust Mgmt

  11. Sp ID# attr[] More details Client authentication of service Lookup Service (1) discovery (1) discovery serviceItem (2) query(attr[]) (2) ServiceRegis (w/ ID) (3) serviceItem[] (3) register(Sp, ID, attr[]) Client Service ID# Extract key/auth info from attr[] credentials Sp attr[] (5) Trust proof or yes/no TM Engine (4) query(key, trust credentials) PKI / Trust CA (not a peer) Database and cache; Fetches credentials Constructs auth proof

  12. Peer-to-peer systems • Several recent systems in use • Napster, Gnutella, Freenet, Casino 2000, … • Move toward decentralized peer-to-peer services • Basic functions • Maintain decentralized network of active peers • Search active peers for document, other resource • Problems • Gnutella uses DFS, Freenet uses BFS, both wasteful • How to maintain network of active peers efficiently • How to query active peers and forward responses • How to evaluate, analyze, simulate system

  13. Peer-to-peer effort • Study existing systems • Install, test, analyze Gnutella, Freenet, … • Build ns (network sim) test environment (in progress) • Design improved protocols (in progress) • Efficient discovery and query • Consider applications • Public key infrastructure • Nameserver for Baker’s MobilePeople architecture • Close analogy to ad hoc wireless routing

  14. Trust Management • Problem: Authentication and trust • Service may not be what client wanted • Client may not be authorized for service • Solution: Trust management • Decentralized security management based on authorities granted to a cryptographic key • Distributed policy determined by service policies and delegation (ability to transfer partial authority) Compliance Checker Request Yes/No Proof Policies Credentials

  15. Trust management progress • Study revocation • Feigenbaum and Li • Comparison with other mechanisms • Chander, Dean, Mitchell • Begin development of Role-based trust mgmt • Increase expressiveness, appropriate for trust based on role of individual in organization • Begin study of distributed implementation • Current experimental implementations require centralized deduction (Prolog theorem prover)

  16. Role-Based Trust Management • Background • Traditional role-based access control lacks • distributed roles, distributed credentials, role-delegation • Existing trust management lacks: • explicit support for roles, the ability to use partial rights • Approach • Principals named by Entities and Roles • e.g., companyA’s employee • Permissions: assigned to roles by distributed policy • Role-delegation • Request with a role

  17. Work in progress on RBTM • Identify concepts for dynamic coalitions • role-delegation • role-formula • Develop logic-based language for concepts • Implement a RBTM engine that • manages roles and credentials for entities • does distributed certificate discovery • Integrate RBTM engine into Jini framework

  18. Why isn’t SPKI/SDSI the answer? • Problems with delegation and names • Delegation from SPKI, local names from SDSI • Need better integration to be useful • SPKI/SDSI lacks some desirable features • intersections of names • parameterized names K_hospital's physician(alice) • Some issues not addressed by SPKI/SDSI • Distributed certificate discovery • find a certificate chain in a set of credentials • Privacy issues, deliver minimal certificates, etc. • Need better implementation of superset of subset of SPKI/SDSI

  19. Protocols • Reliability • Routing protocols assume nodes follow protocol • Investigate problems caused by misbehavior • One solution: improve throughput by monitoring • Correctness • Model checking • Exhaustively check all states of a system • Works only for finite-state model • Predicate abstraction • Use automatic theorem proving for arbitrary size system • Reduce unbounded system to finite-state approximation

  20. Background: Ad hoc routing • Mobile wireless network • composed of limited range wireless devices • no dedicated routers • Several routing protocols proposed • Dynamic Source Routing (DSR) • On-demand source routing, maintains route cache • Ad hoc, On-demand, Distance Vector routing (AODV) • Not source routing; node only knows what’s next S D

  21. Node Misbehavior • Node agrees to forward other nodes’ packets but instead drops the packets • Reasons for node misbehavior: • Malicious nodes mounting denial of service attacks • Selfish nodes conserving resources • Overloaded nodes • Broken software

  22. Solutions • Watchdog and Path Rater mitigate the effects of node misbehavior • Assumptions • Bi-directional links • Promiscuous mode • Philosophy: avoid adding more complexity to the routing protocol

  23. Watchdog • Forwarding node verifies next node passes on packet • Watchdog notifies source of possible node misbehavior B A C S D A listens to B forwarding to C

  24. B A C S D Path Rater • Rate nodes based on reliability (as reported by watchdog) • Node rating initially neutral • Misbehaving node gets strongly negative rating • Increment rates of nodes on active paths • Decrement rating of nodes on paths if link-break occur • Pick path with highest average rating • Fallback: route discovery • If all known paths contain misbehaving nodes, run Path Rater Route Request (PRRR)

  25. Throughput • 17% improvement at 40% misbehaving (low mobility) • 27% improvement at 40% misbehaving (high mobility)

  26. Overhead Results

  27. Protocol correctness • Protocols are notoriously difficult to design • Goal: make formal verification techniques applicable to important network protocols • Approach: • Model checking systematically generate states of a system for fixed numbers of nodes • Mature; works only for finite-state models. • Predicate abstraction uses automatic theorem proving to verify for any number of nodes. • New: works for descriptions with unbounded states.

  28. Predicate abstraction Reduce verification of large or infinite-state systems to standard finite-state model checking Protocol description Predicate abstractor FSM checker Abstract FSM Properties to check Simple Predicates (e.g. x > 0)

  29. Predicate Abstraction Details • Prototype checker exists • Combines several different libraries • SVC: “Stanford Validity Checker” (automatic theorem prover) • BDD-based model checking • uses Boolean functions to represent FSMs and their states • Performance increased 10-fold in last 2 months • Successive approximation based on counterexamples. • Used on AODV and cryptographic protocols

  30. AODV • “Ad hoc, On-demand, Distance Vector routing” • Automatically assemble networks of mobile nodes • Routes are required to be loop-free • Routes may fail if loops exist • Route loops found using Mur model checker • During timeout of routes • previously discovered by Broch and Maltz of CMU • During processing of RERR messages • previously unknown; newly introduced in AODV version 4 AODV is broken. Can we fix it?

  31. AODV Modification • Changed protocol to eliminate (?) loops • Mur verification with 4 nodes found no problems • Found bugs in “fixed” protocol • Use predicate abstraction to study larger networks • Problem results from arbitrary message delays • Example requires 5 nodes (too big for Mur !) • Goal • Complete repair of AODV protocol • Verify version 5 of AODV using predicate abstraction

  32. Jini architecture Code filter Architecture design Implementation of some parts in progress Peer-to-peer Evaluate current systems coalition discovery and search problems network simulation Trust management Comparison with other access control mechanisms Identify role-based TM Implementing inference engine Protocols (ad hoc wireless routing) Improve DSR reliability watchdog, pathrater Discover looping in AODV Formal tools find new bugs Progress Summary

  33. Deliverables • Upcoming Year 1 report deliverables • 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 • Architecture for trust management used negotiations for dynamic coalitions, • Mobile-code security mechanisms in Jini environment

More Related