Policy Management and Policy. Guided Interactions in Ubiquitous Computing Environments V. Ramakrishna Ph. D Dissertation Computer Science Department, UCLA September 19 th, 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 l l l 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 l l l 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 l l l 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 Characteristics Ø Blurred distinction between producer and consumer ØDecentralized control ØØHeterogeneity prior trust No guarantee of relationships or shared ØAd hoc interactions protocols SPONTANEOUS INTEROPERATION Introduction Home Network Internet News / Game / Streaming Video (WEB services) – Solution – System – Analysis and Testing – Related Work – Conclusion
7 Our View of Interoperation l l l 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 A Smart Ubiquitous Conference Room ØServices Offered: Internet, printer, display. ØAccess Control: Only conference officials may access the projector display. Internet ØPolicy: No sound permitted during conference hours. ØPossession: NSF credentials. CONFERENCE ATTENDEE (an ACM member) (Already a member of the network) PRIVILEGED ACCESS ØRequires: Web access, Projector display, Printer. PDA – CELL PHONE (Possessed by a conference attendee) ØPossession: UCLA credentials. ØPrivacy Concern: Release of credential 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 l l l 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 l l l Existing interaction procedures • • Too open and lacking security, OR Secure but too inflexible • • Loss of privacy and autonomy Does not scale; e. g. , Smart Spaces • • 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 Centralized or third party control Separate protocols for each scenario Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
12 Service or application layer agreements l l Based on policy Through a process of negotiation Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
13 Platform and Assumptions APPLICATION TRUST PROOF / LOGIC / RULES NEGOTIATION FOR SERVICE ACCESS OUR PROTOCOL NEGOTIATION FOR SERVICE ACCESS 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 l l l 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 l l 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 l l 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 Constraints: Deontic, Limits, Precedence Relationships among Data and Resources POLICY ONTOLOGY Contextual Parameters: Location, Time, etc. Attributes: Characteristics, Metadata POLICY CLASSES Ø Resource Usage Ø Security and Access Control Ø Context Awareness Actions and Events Mechanisms and Protocols: Sensors, Networking, Cryptography Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
18 Negotiation Model D 1 D 2 Decentralized policy resolution Bidirectional protocol Multiple simultaneous objectives G 1 P 1 S 1 Grant access to service set Q 1 G 1 Q 2 Introduction – Solution G 2 P 2 S 2 Grant access to service set Q 2 Goals/Requirements G 2 S 1 Resources and Services Policies – System – Analysis and Testing – Related Work – Conclusion
19 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. Internet OFFER: (1) YES [voucher], (2) YES, (3) NO OFFER: (1) NO (2) NO (3) ‘ 2. 6. 17. 1’ OFFER: (6)(4) YES [NSF voucher object] voucher OFFER: YES [UCLAprivilegedobject] OFFER: Journal membership 25 closed] (5)access (4) YES [Port for YES CONFERENCE ATTENDEE C 1 (an ACM member) REQUEST(Counter): (6) Valid accreditation from ACM-affiliated school? REQUEST(Counter): (4) Valid NSF accreditation? REQUEST(Counter): (1) Valid ACM voucher? (2) Valid ACM Official voucher? (3) What OS do you run? PRIVILEGED ACCESS (4) Close port 25 (5) Turn off sound REQUEST: (1) Membership (2) Printer access (3) Projector display access Introduction – Solution PDA – CELL PHONE Requires Membership for web access; AND Projector display access; AND Printer access. – System – Analysis and Testing – Related Work – Conclusion
20 Negotiation: Who? l Two-party negotiation • A wants something from B and vice-versa, • l 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? l 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 l l 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 l 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 certificate(‘UCLA’). certificate(‘NSF’), possess(‘NSF’). file(‘song. mp 3’, audio), possess(‘song. mp 3’). RULES member(X) : - candidate(X), possess(X, V), valid. Credential(V) : - certificate(V). valid. Credential(V) : - certified. By(V, ’ACM’). Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
24 Policy Language (Continued) l Generality vs access(E, R) : - some. Constraint(E, R). l Local predicates vs door(X), party. Member(X). l System policies access(entity, resource). global predicates certificate(X), printer(X). vs action(close. Port, Po) : atom_concat(‘iptables –A INPUT –j DROP –p tcp – dport’, Po, C 1), atom_concat(C 1, ’-i eth 1’, C), shell(C). l specificity User policies 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 l l Units: messages representing speech acts • Utterances that express intent to perform an action Categories: Speech Acts Message Type l l Directive Commissive Assertive Declarative REQUEST OFFER POLICY TERMINATE 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 l l l Requests • • • Action <Do A> Action <Allow me to do A> Possession <Give me P> State <Let me change to state S> Question <Tell me …> • Obligation <Promise to abide by O> • • 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> Policies Offers Each message can contain multiple requests/offers Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
27 Protocol State Machine STAR T Receive REQUESTS / POLICIES Trigger/Event to Start Negotiation Receive OFFERS INITIATE PROCESS SERVICE Send REQUESTS / POLICIES / OFFERS Send REQUESTS / OFFERS / POLICIES Receive OFFERS Receive REQUESTS / POLICIES EXPECT Receive TERMINATE / TIMEOUT Send TERMINATE STOP Send TERMINATE Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
28 Yes INITIATE NEGOTIATION? START INITIATE More Requests No PUSH REQ/POL onto REQUESTS-MADE STACK MESSAGE-TYPE == OFFER PROCESS EXPECT No RECEIVE MESSAGE No SEND SET of <REQ/POL> Other No No SERVICE PUSH REQ/POL onto REQUESTS-RECEIVED STACK Request / Policy More Requests No OFFER = AFFIRMATIVE / NEGATIVE / ALTERNATIVE ? SAVE OFFER to REJECT Negative No Yes POP REQ from REQUESTS-MADE STACK POP REQ from REQUESTS-RECEIVED STACK REGISTER CHANGES in POLICY DATABASE SAVE OFFER to SEND No ALTERNATIV E OFFERS AVAILABLE? PUSH REQ/POL onto REQUESTS-MADE STACK No More Requests No More Offers COUNTERREQUESTS GENERATED ? Yes SEND SET of <REQ/POL> SEND OFFER <REQ/POL> = SELECT and REMOVE from ALTERNATIVES SET Yes No REQUESTSRECEIVED STACK EMPTY? SEND SET of <REQ/POL> No More Requests SAVE ALTERNATIVES = COUNTERREQUESTS SET - <REQ/POL>: <RECEIVED REQ/POL ALTERNATIVE SET of COUNTER_REQ> Yes More Requests GENERATE FALSE OFFER SELECT OFFER and SAVE the REST Yes No PUSH REQ/POL onto REQUESTS-MADE STACK Yes More Requests REMOVE INVALIDATED ALTERNATIVES ALTERNATIV E REQUEST AVAILABLE? ALTERNATIV E OFFER OK? GENERATE MATCHING ALTERNATIVE OFFERS <REQ/POL> = SELECT from COUNTER-REQUESTS SET GENERATE FALSE OFFER Affirmative GRANT REQUEST? Yes GENERATE COUNTERREQUESTS AND POLICIES COUNTERREQUESTS AVAILABLE ? SAVE OFFER to SEND Alternative No More Requests No Yes ALTERNATIV E OFFERS AVAILABLE? Yes OFFER ACCEPTABLE ? More Offers PROCESS OFFER INTEGRIT Y VERIFIED ? Yes SAVE OFFER to SEND MESSAGE TYPE? LOOKUP OFFER from STORED ALTERNATIVES VERIFY OFFER VERACITY More Offers OFFERS to SEND? Yes OFFERSUBTYPE == REJECT? MESSAGE-TYPE == TERMINATE COUNTERREQUESTS GENERATED ? No Yes SEND TERMINATION LOOKUP OFFER to SEND RECEIVE MESSAGE STOP RE-EVALUATE REQUESTS in REQUESTS-RECEIVED STACK More Requests EXPECT More Satisfied Offers No SEND OFFER LOOKUP OFFER to SEND More Satisfied Offers
29 Negotiation Protocol l POSED D 1→D 2 Series of REQUESTs and OFFERs Reply to a REQUEST could be • • An OFFER (positive/negative) A set of Counter-REQUESTS RECEIVED D 2→D 1 OFFER: R 24 R 15 R 14 D 1 R 11 R 24 R 23 R 21 R 15 R 14 R 13 R 12 R 11 R 13 R 12 Each side maintains two REQUEST lists • • • Requests received, and Requests posed Lists grow with additional counter-REQs Lists shrink with OFFERs (rollback) D 2 l Termination: both lists become empty l POSED RECEIVED An agreement has been achieved D 2→D 1 D 1→D 2 Typical requests tested: credentials, attributes and state queries • Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
30 Generation of Counter-Requests l l l A constraint-extraction algorithm Request: {member} Formatted predicate • {member(S)} → INPUT Relevant facts • possess(‘HP 7200’); printer(‘HP 7200’); group. Size(5); trusted. Domain(‘ACM’); trusted. Domain(‘UCLA’) Relevant policy • member(S) : - sound(S, prohibit, 1000, 1500), group. Size(G), G>4, closed. Port(S, 25), possess(S, V), voucher(V, M), trusted. Domain(M). l Extracted request set alternatives → OUTPUT • • {sound(prohibit, 1000, 1500); action(order, close. Port, 25); possess(V), voucher(V, ’ACM’)} {sound(prohibit, 1000, 1500); action(S, order, close. Port, 25); possess(S, V), voucher(V, ’UCLA’)} Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
31 Negotiation Model: Distributed Policy Resolution l l 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 l l 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 Ubiquitous Policy Manager: Design and Implementation l Prerequisite: an environment/platform that supports collections of devices and offers services • l PANOPLY: a middleware that manages devices clustered in spheres of influence Policies mediate interactions among devices and collections of devices Introduction – Solution – System APPLICATIONS EVENT PROCESSOR PANOPLY MIDDLEWARE POLICY MANAGER SPHERE MANAGER OPERATING SYSTEM NETWORK – Analysis and Testing – Related Work – Conclusion
34 Policy Management in Panoply l Primary task: negotiation between spheres for membership and service access • Support for renegotiating agreements l l Arbitrate access to resources through negotiation Event-action triggers Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
35 Concurrent Negotiations in Panoply APPLICATIONS EVENT PROCESSOR POLICY MANAGER SPHERE MANAGER OPERATING SYSTEM NETWORK Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
36 Policy Manager - Functional View Messaging Interface (To other system components, remote computers) FRONT END Protocol State Machine Multi-Threading and Message Switching Fault Tolerance Observer/Event Listener Handle node/network Fault Tolerance conditions failure and race Use timeouts and unique timestamps per thread CONTROLLER Request Queue Formulation and Non-logical operations Interfacing with Interpretation of Messages Interfacing with Helper Functions Management Semantic ØProcessing of objects (say Java objects) Helper Functions ØOperating system operations Security/Trust Model Negotiation Heuristics Example: sign and verify a voucher POLICY ENGINE Logical Knowledge Engineering Mechanisms Introduction – Solution – System Policy Database – Analysis and Testing – Related Work – Conclusion
37 Applications l l l 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 Externa l Sphere Events EVENT PROCESSOR . . . POLICY MANAGER SPHERE MANAGER Externa l Sphere Introduction – Solution – RUN NEGOTIATE DROP PASS QUERY OPERATING SYSTEM NETWORK System – Analysis and Testing – Related Work – Conclusion
39 Application: The Smart Party Cooperative music application deployed in a multiroom environment l l l Users bring mobile devices carrying music and musical preferences Each room builds custom playlist based on user presence and preferences Dynamically streams music from attendees Smart Party Living Room Family Room Dining Room Folk Rock Jazz Rap R&B [Eustice 2008: Ph. D Thesis] Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
40 Access Control in a Smart Party l l l 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 Case I: R(N 1) AO(N 2) T(N 1) Case II: R(N 1) NO(N 2) T(N 1) Case III: R(N 1) 3 C-R(N 2) 3 AO(N 1) AO(N 2) T(N 1) Case IV: R(N 1) C-R(N 2) NO(N 1) 3 C-R(N 2) (alternative) 3 AO(N 1) 1 AO(N 2) T(N 1) Introduction – Solution – System – Analysis and Testing N 1 802. 11 b TLS N 2 Initiator R(N 1) == Request for membership – Related Work – Conclusion
42 Analysis: System Perspective l l 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)2 FS 2 A) 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 l Primary negotiation aim: given goals and policies, generate a result • • l l Set of results ranging from none to full satisfaction of goals Collection of such results are consistent with policies Knows <G 1, P 1, S 1> and <G 2, P 2, S 2>, and uses a centralized resolution algorithm to determine the best result Complexity is still exponential • • • Need to keep local policies private Must work with partial knowledge Ideal: achieve the oracular result An oracle (centralized policy resolution) can generate an optimal solution Negotiation is a decentralized policy resolution Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
44 Grades of Success l l l Correctness: • • Result (set of goal satisfactions) is an improper subset of the oracular result Only criteria: consistency with policy • Negotiation protocol delivers oracular result in fewest number of steps Completeness: Optimality: Correctness < Completeness < Optimality Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
45 Analysis: Theoretical Perspective l Correctness and Completeness? : YES, with Exception Trivially correct in all cases • l Guaranteed to terminate in a finite number of steps • l • Exhaustive search ensures that a solution will be found • • Database has finite number of policies Each policy is of finite length • End result of negotiation guaranteed to be consistent with policy, as Prolog query semantics are known to be correct 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 • Negotiation time and #steps depend on alternative selection ordering Optimality? : NO GUARANTEE Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
46 Optimality Testing l l 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 l l Negotiation Protocol (decentralized PR) Centralized Policy Resolver: Oracle Inputs • Process • l • Outputs • Two policy databases and an initial goal (request) • Combine two policy databases into a centralized one • 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 l Pair of policy databases and goal sets l Variations based on size of tree • One for each negotiator • 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
51 Processing Time Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
52 Processing Time Per Step Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
53 Results Summary l Actual negotiation increases linearly with the optimal negotiation length • l l l Average length of failed negotiations < 4 steps Negotiation processing time dominates oracular processing time, but not the average time per step Increase in policy complexity results in significant increase in processing cost (but mainly for bmax >= 6) Fraction of intermediate requests granted and alternatives examined show small variations but are significantly lower than unity on average Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
54 Related Work l Negotiation Protocols Automated Trust Negotiation • l • Web services negotiation (WS-Agreement) • • Protune, Peer. Trust, Trust. Builder [BYU, UIUC] Goal: client-server transactions on the Web Does not support alternatives or multiple goals No comparison with centralized model Policy Languages • Rei pervasive computing language • Cross-domain semantics • Web services: WS-Policy, XACML: non-logical • Ponder: non-logical • Ontology: SOUPA, DAML+OIL, OWL Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
55 Related Work (Continued) l l l Middleware for open systems • • • Ubicomp active space middleware – Hyperglue [MIT], Cerberus [UIUC] Service discovery – JINI, UPn. P Limited security features • • • Generalized RBAC Dynamic RBAC Secure Context-sensitive Authorization [Minami and Kotz] Access Control • • Distributed Proof Test Case Generation Trust frameworks • SECURE project • Reputation frameworks • • Dynamic notion of trust Trust evolution based on interaction history Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
56 Future Work l l l Enhancements to the negotiation protocol • • • Other heuristics: expected time to finish, partial ordering based on privacy and trust Multi-party collective negotiation Avoiding Do. S attacks • • Running on resource-constrained devices Porting to other middleware; e. g. , GAIA • • • More control and feedback Post-negotiation analysis User-friendly policies Policy Manager User Interaction Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
57 Conclusion l l l Service-level interoperation in ubicomp requires • • Flexible solutions Minimal user intervention Generic policy-guided negotiation enables interoperation Negotiation is modeled as a distributed policy resolution procedure Proof-of-concept was demonstrated through a working implementation and practical applications Negotiation can be used as a tool for dynamic context-sensitive access control Large-scale optimality tests indicate feasibility of negotiation in practical situations Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
58 Thank You l l l V. Ramakrishna, Kevin Eustice, and Peter Reiher, “Negotiating Agreements Using Policies in Ubiquitous Computing Scenarios, ” In the Proceedings of the IEEE International Conference on Service-Oriented Computing and Applications (SOCA'07), June 19 -20, 2007, Newport Beach, California. Venkatraman Ramakrishna, Peter Reiher, and Leonard Kleinrock, “Distributed Policy Resolution Through Negotiation in Ubiquitous Computing Environments, ” In submission to the 7 th Annual IEEE International Conference on Pervasive Computing and Communications (Per. Com 2009). Kevin Eustice, Leonard Kleinrock, Shane Markstrum, Gerald Popek, Venkatraman Ramakrishna, Peter Reiher, “Enabling Secure Ubiquitous Interactions, ” In the Proceedings of the 1 st International Workshop on Middleware for Pervasive and Ad-Hoc Computing (Co-located with Middleware 2003), 17 June 2003 in Rio de Janeiro, Brazil. Kevin Eustice, V. Ramakrishna, Alison Walker, Matthew Schnaider, Nam Nguyen and Peter Reiher, "nan 0 sphere: Location-Driven Fiction for Groups of Users, " In the Proceedings of the 12 th International Conference on Human. Computer Interaction (HCII 2007), 22 -27 July 2007, Beijing, P. R. China. Kevin Eustice, V. Ramakrishna, Nam Nguyen, and Peter Reiher, "The Smart Party: A Personalized Location-aware Multimedia Experience, " In the Proceedings of the Fifth IEEE Consumer Communications and Networking Conference (CCNC 2008), Las Vegas, NV, January 10 -12, 2008.
![59 Case Study: Secure Perimeters OFFER: (2) YES [UCLA OFFER: (1) YES Voucher] (3)](https://present5.com/presentation/941222b5d27a37bb8d274675ace05b2e/image-59.jpg "59 Case Study: Secure Perimeters OFFER: (2) YES [UCLA OFFER: (1) YES Voucher] (3)")
59 Case Study: Secure Perimeters OFFER: (2) YES [UCLA OFFER: (1) YES Voucher] (3) YES OFFER: (4) YES NO OFFER: (2) YES [Result] OFFER: (5) NO OFFER: (1) (3) Firewalled Local Network REQUEST (Counter): (2) Credentialed by UCLA? (3) Let me run networked applications REQUEST (Counter): (5) Close port 25 REQUEST: (1) Membership REQUEST (Counter): (2) Are you running Redhat? REQUEST (Counter): (4) Upgrade Kernel REQUEST (Counter): (1) Are you running Ubuntu? (3) v 2. 6. 20 or higher? Introduction – Solution – System – Analysis and Testing – Related Work – Conclusion
60 Case Study: Interactive Narrative l l Team-, location- and actiondriven fiction deployed in UCLA Purposes of negotiation • • • l Membership within location and team spheres Obtain location voucher Variations • Dynamic role change Policy manager roles • Hints based on context and location changes
61 Sample Test Case Rules Facts storage(px 6). voucher(ht). type(zp, bw). voucher(vk). printer. Name(pjf). disp(l). group(py, acm). tim(gh). brand(o, hp 7100). parent. Name(htm). possess(disk. Space, 0). display. Name(ck). directory(ec, v). file(fi 1). type(xz 1, color). voucher(c). obey(X, open) : - printer(VAR), display. Name(X, VAR 001723). access. Info(X, (tim(VAR 01213))) : - possess(X, VAR 0683), voucher(VAR 0683), type(VAR 0683, VAR 1684). access(X, disk. Space, VAR) : - child. Name(X, VAR 023638). obey(X, run) : - voucher(VAR), type(VAR, VAR 1), possess(X, disk. Space, VAR 1610). obey(X, open) : - printer(VAR), member. In(X). obey(X, open) : - printer(VAR), child. Name(X, VAR 023592). access. Info(X, (tim(VAR 01213))) : - possess(X, disk. Space, VAR 1573). access. Info(X, (tim(VAR 01011))) : - action(X, order, open, VAR 0554), printer(VAR 0554). access. Info(X, (child. Name(VAR 023))) : - member. In(X). obey(X, open) : - printer(VAR), possess(X, disk. Space, VAR 1481). access. Info(X, (child. Name(VAR 023))) : - display. Name(X, VAR 001382). access(X, VAR) : - voucher(VAR), type(VAR, VAR 1), child. Name(X, VAR 023354). obey(X, run) : - voucher(VAR), type(VAR, VAR 1), action(X, order, open, VAR 0144), printer(VAR 0144). Sample Goals possess(VAR), door(VAR) action(order, play, VAR), door(VAR), directory(VAR, VAR 1) action(order, close. Port, VAR), door(VAR), type(VAR, VAR 1) action(order, prohibit, VAR), printer(VAR), brand(VAR, VAR 1)
Скачать презентацию Policy Management and Policy Guided Interactions in Ubiquitous
941222b5d27a37bb8d274675ace05b2e.ppt