Policy Management and Policy-Guided Interactions in Ubiquitous Computing Environments

1. Policy Management and Policy-Guided Interactions in Ubiquitous Computing Environments V. Ramakrishna PhD Dissertation Computer Science Department, UCLA September 19th, 2008

2. Thesis Statement Automated negotiation for generation of service access agreements in ubiquitous computing environment can be achieved through a generic protocol guided by the participants’ policies.

3. Research Contributions • General purpose negotiation protocol for exchange of information through speech acts • Modeling negotiation as a distributed/decentralized policy resolution procedure for agreement generation • Implementation of negotiation within a policy management subsystem for ubiquitous devices and groups • Dynamic context-sensitive access control through negotiation • Building of a test case generator and large scale performance comparisons between centralized and decentralized policy resolutions

4. Outline • Introduction and Motivation • Solution Model and Procedures • System Design and Implementation • Analysis and Testing • Related Work • Future Work and Conclusion

5. The Ubiquitous Computing Scene • Goal: automated unobtrusive service access anywhere and at any time (Weiser 1991) • Where are we? • Standardized seamless networking technologies • Mobile devices and agents • Smart spaces aware of occupants identities and needs • What is lacking? • Automated configuration and facilitation of interactions between mutually unknown computers or agents • Balancing automation with security and privacy concerns Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

6. Ubiquitous Computing Characteristics PHYSICAL INTEGRATION: DEVICES, NETWORKS & SERVICES Coffee Shop Personal Network • Accessing Services • Intertwined processes of discovery and access control • Blurred distinction between producer and consumer • No guarantee of prior trust relationships or shared protocols Home Network Internet • Characteristics • Decentralized control • Heterogeneity • Ad hoc interactions News / Game / Streaming Video (WEB services) SPONTANEOUS INTEROPERATION Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

7. Our View of Interoperation • A top-down approach: abstract common features from different scenarios • Incorporate safety and privacy bottom-up • Achieve service access agreements across security and administrative domains while • Preserving autonomy of intent and action • Limiting or eliminating manual intervention Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

8. Internet A Smart Ubiquitous Conference Room • Services Offered: Internet, printer, display. • Access Control: Only conference officials may access the projector display. • Policy: No sound permitted during conference hours. • Possession: NSF credentials. CONFERENCE ATTENDEE (an ACM member) (Already a member of the network) PDA – CELL PHONE (Possessed by a conference attendee) • Requires: Web access, Projector display, Printer. • Possession: UCLA credentials. • Privacy Concern: Release of credential PRIVILEGED ACCESS Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

9. Guarding Network Perimeters • Requires: Network Access, Run network apps. • Privacy concern: Releasing configuration info. • Compromise: Stop vulnerable services. • Access Control: Will run arbitrary code only from trusted source. Firewalled Local Network • Service Offered: Network connectivity. • Access Control: Based on device’s configuration. • Security Constraint: Members may run only safe networked applications. • Policy: Prospective client must reveal configuration information. Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

10. Roadblocks and Challenges • Cannot prepare for every interaction context • Cannot identify, or have pre-arranged trust relationships with, everyone else • Heterogeneity of device characteristics, service types and grades • Difference in policies (goals and constraints) • Interdependence of resources, entities, and constraints within a domain Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

11. Solutions That Don’t Work • Existing interaction procedures • Too open and lacking security, OR • Secure but too inflexible • Centralized or third party control • Loss of privacy and autonomy • Does not scale; e.g., Smart Spaces • Separate protocols for each scenario • Contexts * Service types and access modes * Interacting entities  Combinatorial explosion • We should be able to control our domains through policies rather than inventing new mechanisms Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

12. Service or application layer agreements • Based on policy • Through a process of negotiation Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

13. Platform and Assumptions APPLICATION APPLICATION TRUST PROOF / LOGIC / RULES NEGOTIATION FOR SERVICE ACCESS NEGOTIATION FOR SERVICE ACCESS OUR PROTOCOL Semantic Web ONTOLOGY / RDF NAMESPACES / XML URI / HTTP Internet / World Wide Web TCP/IP MAC LAYER NETWORK PHYSICAL LAYER Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

14. All Interacting Devices Share • Low level n/w mechanisms, like TCP/IP • Secure communication protocols, like TLS • Some common understanding of higher (application layer) objects • Popularity of Semantic Web technologies (RDF/XML) validate this assumption Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

15. Autonomous Domains • Classes: • Single computing device • Networked group of computing devices • Devices affiliated to an organization • Defined administrative boundary with independent policies • Capable of autonomous computing and communication • Offer services and run applications Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

16. Domain Policies • Represents desired system behavior, goals and choices • Collection of facts, invariants and rules • Specified by users • Changes based on observations • Knowledge of policies is private by default • Minimum common abstraction necessary for interaction • Policy is the only domain-dependent variable Enables control over domain behavior of the scope and flexibility required in ubiquitous computing Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

17. Policy Classes and Ontology Autonomous Entities (Including Agents) Resources and Data Relationships among Data and Resources POLICY CLASSES Constraints: Deontic, Limits, Precedence • Resource Usage • Security and Access Control • Context Awareness POLICY ONTOLOGY Attributes: Characteristics, Metadata Contextual Parameters: Location, Time, etc. Actions and Events Mechanisms and Protocols: Sensors, Networking, Cryptography Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

18. Q1 G1 S2 Q2 G2 S1 Goals/Requirements Resources and Services Policies Negotiation Model D1 D2 Decentralized policy resolution Bidirectional protocol Multiple simultaneous objectives G1 G2 P1 P2 Grant access to service setQ1 S1 S2 Grant access to service setQ2 Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

19. Internet Scenario – Conference Room Membership Policy Membership will be granted if you are certified by ACM or an ACM affiliated organization; AND if you are running a trusted OS version; AND if you are willing to shut off port 25; AND if you are willing to turn off sound. OFFER: (1) YES [voucher], (2) YES, (3) NO OFFER: Journal membership for privileged access OFFER: (6) YES [UCLA voucher object] OFFER: (1) NO (2) NO (3) ‘2.6.17.1’ (4) YES [Port 25 closed] (5) YES CONFERENCE ATTENDEE C1 (an ACM member) OFFER: (4) YES [NSF voucher object] REQUEST(Counter): (6) Valid accreditation from ACM-affiliated school? REQUEST(Counter): (4) Valid NSF accreditation? PDA – CELL PHONE REQUEST(Counter): (1) Valid ACM voucher? (2) Valid ACM Official voucher? (3) What OS do you run? (4) Close port 25 (5) Turn off sound Requires Membership for web access; AND Projector display access; AND Printer access. PRIVILEGED ACCESS REQUEST: (1) Membership (2) Printer access (3) Projector display access Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

20. Negotiation: Who? • Two-party negotiation • A wants something from B and vice-versa, within A’s and B’s policy constraints • Bilateral one-to-one (concurrent) negotiations supported • Multi-party negotiation left for future work • Much harder to analyze theoretical properties like completeness Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

21. Negotiation: What? • What do they negotiate for? • Resource access • Information and data transfer • Imposition of obligations • Permissions to perform actions (typically, running operating system and network services) Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

22. Domain Policy Model • Individual policy statements specified in a declarative logical manner • Policies collectively comprise a database • Logically consistent statements • Permits both examination and modification operations • Policies can be related to each other • Offer an interface to return answers to suitably framed logical queries • Return unambiguous answer to a query • Return satisfied and unsatisfied conditions Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

23. Policy Language • Prolog syntax and semantics • Facts and rules • Predicates and arguments • Logical reasoning mechanisms for querying: backward chaining, unification • Negation-by-failure • Sound, and efficient for our purposes FACTS RULES certificate(‘UCLA’). certificate(‘NSF’),possess(‘NSF’). file(‘song.mp3’,audio), possess(‘song.mp3’). member(X) :- candidate(X), possess(X,V), validCredential(V). validCredential(V) :- certificate(V). validCredential(V) :- certifiedBy(V,’ACM’). Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

24. Policy Language (Continued) • Generality vs specificity access(E,R) :- someConstraint(E,R). access(entity,resource). • Local predicates vs global predicates door(X), partyMember(X). certificate(X), printer(X). • System policies vs User policies action(closePort,Po) :- atom_concat(‘iptables –A INPUT –j DROP –p tcp –dport’,Po,C1),atom_concat(C1,’-i eth1’,C),shell(C). access(S,V) :- certificate(V), possess(S,’NSF’). • Helper Functions action(prohibit,sound) :-shell('amixer set Master mute',0). Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

25. Basis of Negotiation • Units: messages representing speech acts • Utterances that express intent to perform an action • Categories: • A negotiation is a conversation • Sequence of speech acts • Illocutionary logic describes rules for appropriate responses • Utility: capture wide range of scenarios Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

26. Message Types and Contents • Requests • Action <Do A> • Action <Allow me to do A> • Possession <Give me P> • State <Let me change to state S> • Question <Tell me …> • Policies • Obligation <Promise to abide by O> • Offers • Agreement <Yes, I agree to do what you ask> • Refusal <No, I will not do what you ask> • Rejection <I cannot accept your offer> • Answer <Here is what you asked/inquired about> Each message can contain multiple requests/offers Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

27. Protocol State Machine START Receive REQUESTS / POLICIES Trigger/Event to Start Negotiation Receive OFFERS INITIATE PROCESS SERVICE Send REQUESTS / POLICIES / OFFERS Send REQUESTS / OFFERS / POLICIES Send REQUESTS / POLICIES / OFFERS Send TERMINATE Receive OFFERS Receive REQUESTS / POLICIES EXPECT STOP Receive TERMINATE / TIMEOUT Send TERMINATE Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

28. PROCESS MESSAGE-TYPE == OFFER PROCESS INITIATE NEGOTIATION? Yes START OFFER INTEGRITY VERIFIED? OFFER-SUBTYPE == REJECT? INITIATE More Requests Yes No MESSAGE-TYPE == TERMINATE No PUSH REQ/POL onto REQUESTS-MADE STACK No SAVE OFFER to SEND Yes LOOKUP OFFER from STORED ALTERNATIVES VERIFY OFFER VERACITY EXPECT More Offers OFFERS to SEND? RECEIVE MESSAGE No SEND SET of <REQ/POL> ALTERNATIVE OFFERS AVAILABLE? OFFER ACCEPTABLE? Yes Yes Yes SAVE OFFER to SEND PROCESS MESSAGE TYPE? GENERATE FALSE OFFER Other More Offers No OFFER = AFFIRMATIVE / NEGATIVE / ALTERNATIVE? No Negative REMOVE INVALIDATED ALTERNATIVES SAVE OFFER to REJECT SERVICE Alternative PUSH REQ/POL onto REQUESTS-RECEIVED STACK More Requests Request / Policy ALTERNATIVE REQUEST AVAILABLE? Affirmative No ALTERNATIVE OFFER OK? No GRANT REQUEST? No POP REQ from REQUESTS-MADE STACK More Requests Yes Yes Yes GENERATE COUNTER-REQUESTS AND POLICIES <REQ/POL> = SELECT and REMOVE from ALTERNATIVES SET POP REQ from REQUESTS-RECEIVED STACK REGISTER CHANGES in POLICY DATABASE COUNTER-REQUESTS AVAILABLE? GENERATE MATCHING ALTERNATIVE OFFERS No PUSH REQ/POL onto REQUESTS-MADE STACK SAVE OFFER to SEND COUNTER-REQUESTS GENERATED? More Requests Yes ALTERNATIVE OFFERS AVAILABLE? No More Offers REQUESTS-RECEIVED STACK EMPTY? No No <REQ/POL> = SELECT from COUNTER-REQUESTS SET GENERATE FALSE OFFER No No More Requests SELECT OFFER and SAVE the REST Yes Yes PUSH REQ/POL onto REQUESTS-MADE STACK SEND SET of <REQ/POL> Yes RE-EVALUATE REQUESTS in REQUESTS-RECEIVED STACK More Requests No More Requests SEND TERMINATION COUNTER-REQUESTS GENERATED? SAVE ALTERNATIVES = COUNTER-REQUESTS SET - <REQ/POL>: <RECEIVED REQ/POLALTERNATIVE SET of COUNTER_REQ> Yes More Requests EXPECT LOOKUP OFFER to SEND RECEIVE MESSAGE SEND OFFER More Satisfied Offers SEND SET of <REQ/POL> No More Satisfied Offers STOP LOOKUP OFFER to SEND SEND OFFER

29. R15 R14 R13 R12 R11 R15 R14 R13 R12 R11 Negotiation Protocol POSED D1→D2 RECEIVED D2→D1 • Series of REQUESTs and OFFERs • Reply to a REQUEST could be • An OFFER (positive/negative) • A set of Counter-REQUESTS • Each side maintains two REQUEST lists • Requests received, and Requests posed • Lists grow with additional counter-REQs • Lists shrink with OFFERs (rollback) • Termination: both lists become empty •  An agreement has been achieved • Typical requests tested: credentials, attributes and state queries OFFER: R24 R24 D1 R23 R21 D2 R24 R23 R21 POSED D2→D1 RECEIVED D1→D2 Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

30. Generation of Counter-Requests • A constraint-extraction algorithm • Request: {member} • Formatted predicate • {member(S)} → INPUT • Relevant facts • possess(‘HP7200’); printer(‘HP7200’); groupSize(5); trustedDomain(‘ACM’); trustedDomain(‘UCLA’) • Relevant policy • member(S) :- sound(S,prohibit,1000,1500), groupSize(G), G>4,closedPort(S,25), possess(S,V), voucher(V,M), trustedDomain(M). • Extracted request set alternatives → OUTPUT • {sound(prohibit,1000,1500); action(order,closePort,25); possess(V), voucher(V,’ACM’)} • {sound(prohibit,1000,1500); action(S,order,closePort,25); possess(S,V), voucher(V,’UCLA’)} Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

31. Negotiation Model: Distributed Policy Resolution • Goals + Policies + Logical Queries  Agreement • High-level goal: policies must not be violated • Agreement fits within the consistent parts of the negotiators’ policies (disregarding incompatible policies) • Negotiation has the same effect as running a query through a union of the negotiators’ databases Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

32. Protocol as a Distributed Derivation Tree • Centralized resolution generates a tree • Root represents goal • Node  children relation represents a rule • Leaves represent facts • Negotiation generates a similar tree • Difference: nodes distributed amongst negotiators • Node  children relation represents rules and requests • Children  parent relations represents offers Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

33. SPHERE MANAGER APPLICATIONS EVENT PROCESSOR POLICY MANAGER OPERATING SYSTEM NETWORK Ubiquitous Policy Manager: Design and Implementation • Prerequisite: an environment/platform that supports collections of devices and offers services • PANOPLY: a middleware that manages devices clustered in spheres of influence • Policies mediate interactions among devices and collections of devices PANOPLY MIDDLEWARE Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

34. Policy Management in Panoply • Primary task: negotiation between spheres for membership and service access • Support for renegotiating agreements • Arbitrate access to resources through negotiation • Event-action triggers Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

35. APPLICATIONS APPLICATIONS APPLICATIONS EVENT PROCESSOR EVENT PROCESSOR EVENT PROCESSOR POLICY MANAGER POLICY MANAGER POLICY MANAGER SPHERE MANAGER SPHERE MANAGER SPHERE MANAGER OPERATING SYSTEM OPERATING SYSTEM OPERATING SYSTEM NETWORK NETWORK NETWORK Concurrent Negotiations in Panoply Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

36. Policy Manager - Functional View Messaging Interface (To other system components, remote computers) FRONT END Multi-Threading and Message Switching Observer/Event Listener Protocol State Machine Fault Tolerance Handle node/network failure and race conditions Use timeouts and unique timestamps per thread Fault Tolerance CONTROLLER Request Queue Management Security/Trust Model Formulation and Semantic Interpretation of Messages • Interfacing with Helper Functions • Non-logical operations • Processing of objects (say Java objects) • Operating system operations • Example: sign and verify a voucher Negotiation Heuristics Interfacing with Helper Functions POLICY ENGINE Logical Knowledge Engineering Mechanisms Policy Database Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

37. Applications • Group- and context-driven Panoply apps • Interactive Narrative • Smart Party • Smart conference room • Peer-to-peer file sharing • Secure flexible perimeters • Opportunistic configuration • Credential/key • Printer access/command Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

38. Dynamic Access Control APPLICATIONS External Sphere Events Events EVENT PROCESSOR SPHERE MANAGER . . . . . . . . . . . NEGOTIATE RUN QUERY PASS DROP POLICY MANAGER External Sphere OPERATING SYSTEM NETWORK Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

39. Application: The Smart Party Cooperative music application deployed in a multi-room environment • Users bring mobile devices carrying music and musical preferences • Each room builds custom play-list based on user presence and preferences • Dynamically streams music from attendees Smart Party Family Room Living Room Dining Room Folk Rock Jazz R&B Rap [Eustice2008: PhD Thesis] Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

40. Access Control in a Smart Party • Guest tries to force the room to play his favorite song • Query made to Policy Engine • Negotiation: • Do you have a valid host voucher? • YES  Update playlist • NO  Nothing changes Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

41. Sample Performance Results 802.11b TLS N1 N2 Case I: R(N1)  AO(N2)  T(N1) Case II: R(N1)  NO(N2)  T(N1) Case III: R(N1)  3 C-R(N2)  3 AO(N1)  AO(N2)  T(N1) Case IV: R(N1)  C-R(N2)  NO(N1)  3 C-R(N2) (alternative)  3 AO(N1)  1 AO(N2)  T(N1) Initiator R(N1) == Request for membership Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

42. Analysis: System Perspective • Assumptions • Finite policy database • Finite length of each policy statement • No cycles within a database • Protocol termination • Counter-Request generation procedure terminates • Running time complexity = O(R(R+F)2FS2A) • Deadlock-free • Livelocks possible • Cycles between negotiators result in duplicate requests • Can be avoided with checks for duplicates (adds overhead) Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

43. “Success” of Negotiation • Primary negotiation aim: given goals and policies, generate a result • Set of results ranging from none to full satisfaction of goals • Collection of such results are consistent with policies • An oracle(centralized policy resolution) can generate an optimal solution • Knows <G1,P1,S1> and <G2,P2,S2>, and uses a centralized resolution algorithm to determine the best result • Complexity is still exponential • Negotiation is a decentralized policy resolution • Need to keep local policies private • Must work with partial knowledge • Ideal: achieve the oracular result Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

44. Grades of Success • Correctness: • Result (set of goal satisfactions) is an improper subset of the oracular result • Only criteria: consistency with policy • Completeness: • Negotiation protocol delivers oracular result • Optimality: • Negotiation protocol delivers oracular result in fewest number of steps Correctness < Completeness < Optimality Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

45. Analysis: Theoretical Perspective • Correctness and Completeness?: YES, with Exception • Guaranteed to terminate in a finite number of steps • Database has finite number of policies • Each policy is of finite length • Trivially correct in all cases • End result of negotiation guaranteed to be consistent with policy, as Prolog query semantics are known to be correct • Exhaustive search ensures that a solution will be found • Exception • Intermediate negotiation steps involve non-logical operations • Database state modification may cause negotiation failure even when success is possible • FIX: keep track of modifications and undo them • Optimality?: NO GUARANTEE • Negotiation time and #steps depend on alternative selection ordering Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

46. Optimality Testing • Statistical comparison of actual and optimal negotiations • Primary metric: number of steps • Oracle can estimate optimal (least) number of steps • Negotiation is sub-optimal • #steps depends on alternative selection heuristic • Other metrics (time, tree coverage) also measured • Counter-Request selection heuristic used • Size of request set Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

47. Testing Tools • Negotiation Protocol (decentralized PR) • Centralized Policy Resolver: Oracle • Inputs • Two policy databases and an initial goal (request) • Process • Combine two policy databases into a centralized one • Outputs • Full (centralized) derivation tree • Total number of policies examined • Number of steps taken by an optimal negotiation • Test case generator Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

48. Generation of Test Cases • Pair of policy databases and goal sets • One for each negotiator • Variations based on size of tree • Number of nodes in a tree = O(bd) • Control parameters • bmax: maximum branching factor • Indicates length or complexity of policies • dmax: maximum depth • Indicates interdependency of policies Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

49. Negotiation Length Variation (Optimal Steps) Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion

50. Negotiation Length Variation (Branching Factor) Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion