Policy Management and PolicyGuided 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
Characteristics
 Blurred distinction between
producer and consumer
Decentralized
control
Heterogeneity
No guarantee of prior trust
relationships
or shared protocols
Ad
hoc interactions
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



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)
Requires: Web access, Projector
PRIVILEGED ACCESS
PDA – CELL PHONE
(Possessed by a
conference attendee)
display, Printer.
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





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
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



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
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
Decentralized policy resolution
D1
D2
Bidirectional protocol
Multiple simultaneous objectives
G1

G2
P1
S1
Grant access to service set Q1
P2
Q1  G1  S2
Grant access to service set Q2
S2
Q2  G2  S1
Goals/Requirements
Introduction –
Solution
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)OFFER:
YES [voucher],
(1) NO (2)
(2)NO
YES,
(3)(3)
‘2.6.17.1’
NO
OFFER:
(6)(4)
YESYES
[UCLA
voucher
object]
OFFER:
[NSF
voucher
object]
OFFER: Journal
membership
for
privileged
(4)
YES [Port
25
closed]
(5)access
YES
CONFERENCE ATTENDEE
C1 (an ACM member)
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?
PRIVILEGED ACCESS
(4) Close port 25 (5) Turn off sound
REQUEST: (1) Membership (2) Printer access
(3) Projector display access
Introduction –
Solution
Requires
Membership for web access;
AND Projector display
access; AND Printer access.
– 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
access(E,R) :- someConstraint(E,R).

Local predicates vs
door(X), partyMember(X).

System policies
access(entity,resource).
global predicates
certificate(X), printer(X).
vs
action(closePort,Po) :atom_concat(‘iptables –A INPUT –j
DROP –p tcp –
dport’,Po,C1),atom_concat(C1,’-i
eth1’,C),shell(C).

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


Units: messages representing speech acts
•
Utterances that express intent to perform an action
Categories:
Speech Acts
Message Type


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



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
STAR
T
Receive
REQUESTS / POLICIES
Trigger/Event to
Start Negotiation
Receive OFFERS
INITIATE
PROCESS
SERVICE
Send REQUESTS /
POLICIES / OFFERS
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
MESSAGE-TYPE == OFFER
PROCESS
PROCESS
INITIATE
More Requests
No
PUSH REQ/POL onto
REQUESTS-MADE STACK
EXPECT
No
RECEIVE
MESSAGE
No
SEND SET of
<REQ/POL>
Other
No
No
SERVICE
PUSH REQ/POL onto
REQUESTS-RECEIVED STACK
Request / Policy
No
SAVE OFFER to
SEND
Yes
ALTERNATIV
E OFFERS
AVAILABLE?
Yes
OFFER
ACCEPTABLE
?
More Offers
PROCESS
OFFER
INTEGRIT
Y
VERIFIED
?
Yes
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
More Requests
OFFER =
AFFIRMATIVE
/ NEGATIVE /
ALTERNATIVE
?
SAVE OFFER to
REJECT
Negative
GENERATE FALSE
OFFER
REMOVE INVALIDATED
ALTERNATIVES
Alternative
No
More Requests
Affirmative
GRANT
REQUEST?
No
Yes
Yes
GENERATE COUNTERREQUESTS AND POLICIES
POP REQ from
REQUESTS-MADE STACK
POP REQ from
REQUESTS-RECEIVED STACK
COUNTERREQUESTS
AVAILABLE
?
No
REGISTER CHANGES in
POLICY DATABASE
GENERATE MATCHING
ALTERNATIVE OFFERS
SAVE OFFER to
SEND
No
ALTERNATIV
E OFFERS
AVAILABLE?
PUSH REQ/POL onto
REQUESTS-MADE STACK
More Requests
No More
Requests
No More Offers
COUNTERREQUESTS
GENERATE
D?
Yes
Yes
SEND SET of
<REQ/POL>
SEND OFFER
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>
<REQ/POL> = SELECT and
REMOVE from ALTERNATIVES
SET
More Requests
GENERATE FALSE
OFFER
SELECT OFFER and
SAVE the REST
Yes
Yes
PUSH REQ/POL onto
REQUESTS-MADE STACK
Yes
<REQ/POL> = SELECT from
COUNTER-REQUESTS SET
No
ALTERNATIV
E REQUEST
AVAILABLE?
ALTERNATIV
E OFFER OK?
Yes
RE-EVALUATE REQUESTS in
REQUESTS-RECEIVED STACK
COUNTERREQUESTS
GENERATE
D?
No
No
SEND
TERMINATION
More Requests
EXPECT
More Satisfied
Offers
RECEIVE
MESSAGE
LOOKUP OFFER to
SEND
STOP
SEND OFFER
LOOKUP OFFER to
SEND
More Satisfied
Offers
29
Negotiation Protocol



POSED
D1→D2
Series of REQUESTs and OFFERs
Reply to a REQUEST could be
•
•
An OFFER (positive/negative)
A set of Counter-REQUESTS
RECEIVED
D2→D1
OFFER: R24
D1
R15
R14
R13
R12
R11
R24
R23
R21
R24
R23
R21
R15
R14
R13
R12
R11
Each side maintains two REQUEST lists
•
•
•
Requests received, and Requests posed
Lists grow with additional counter-REQs
Lists shrink with OFFERs (rollback)
D2

Termination: both lists become empty

POSED
RECEIVED
 An agreement has been achieved
D2→D1
D1→D2
Typical requests tested: credentials, attributes and state queries
•
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
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
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

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
Concurrent Negotiations in
Panoply
APPLICATIONS
EVENT PROCESSOR
POLICY MANAGER
SPHERE MANAGER
OPERATING SYSTEM
NETWORK
APPLICATIONS
APPLICATIONS
EVENT PROCESSOR
EVENT PROCESSOR
POLICY MANAGER
POLICY MANAGER
SPHERE MANAGER
SPHERE MANAGER
OPERATING SYSTEM
OPERATING SYSTEM
NETWORK
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
Tolerance
Handle node/network Fault
failure
and race conditions
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
Java objects)
Helper (say
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





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
Events
EVENT PROCESSOR
..
..
..
..
..
.
POLICY MANAGER
SPHERE MANAGER
Externa
l
Sphere
Introduction – Solution –
NEGOTIAT
RUN
DROP
PASS
QUERY
E
OPERATING SYSTEM
NETWORK
System
– Analysis and Testing – Related Work – Conclusion
39
Application: The Smart Party
Cooperative music application deployed in a multiroom environment



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
[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
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)
802.11b
N1
N2
TLS
Initiator
R(N1) == Request for membership
Negotiator N2
Negotiator N1
8000
9000
7000
8000
6000
7000
6000
5000
Time in
4000
milliseconds
Wait
Process
3000
Time in 5000
milliseconds 4000
Wait
Process
3000
2000
2000
1000
1000
0
0
I
II
III
I
IV
Negotiation Scenario
Introduction – Solution – System –
II
III
IV
Negotiation Scenario
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
•
•

An oracle (centralized policy resolution) can generate an
optimal solution
•
•

Set of results ranging from none to full satisfaction of goals
Collection of such results are consistent with policies
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
•
Process
•
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

Pair of policy databases and goal sets

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)
40
Mean
Median
35
17.0, 32.7
Negotiation Steps
30
15.0, 27.6
25
13.0, 22.0
20
11.0, 17.7
15
9.0, 13.5
10
7.0, 9.8
5.0, 6.3
5
-1.0, 3.7
3.0, 3.0
0
-2
0
2
4
6
8
10
Optimal Number of Steps
Introduction – Solution – System –
Analysis and Testing
12
14
16
– Related Work – Conclusion
18
50
Negotiation Length Variation
(Branching Factor)
6
Oracle
Negotiation
5.5
Number of Steps
5
4.5
4
3.5
3
2.5
2
0
2
4
6
8
Database Branching Factor
Introduction – Solution – System –
Analysis and Testing
10
– Related Work – Conclusion
12
51
Processing Time
140000
Oracular Tree
120000
Negotiation Tree
Time in Milliseconds
100000
80000
60000
40000
20000
0
-20000
-2
0
2
4
Introduction – Solution – System –
6
8
10
Number of Optimal Steps
Analysis and Testing
12
14
16
18
– Related Work – Conclusion
52
Processing Time Per Step
6000
Oracular Tree
5000
Negotiation Tree
Time in Milliseconds
4000
3000
2000
1000
0
-1000
-2
0
2
4
Introduction – Solution – System –
6
8
10
Number of Optimal Steps
Analysis and Testing
12
14
16
– Related Work – Conclusion
18
53
Results Summary

Actual negotiation increases linearly with the optimal
negotiation length
•



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

Negotiation Protocols
•
•

Automated Trust Negotiation
•
•
•
•
Protune, PeerTrust, TrustBuilder [BYU,UIUC]
Goal: client-server transactions on the Web
Does not support alternatives or multiple goals
No comparison with centralized model
Web services negotiation (WS-Agreement)
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)


Middleware for open systems
•
•
•
Access Control
• Generalized RBAC
•
•

Ubicomp active space middleware – Hyperglue [MIT], Cerberus
[UIUC]
Service discovery – JINI, UPnP
Limited security features
Dynamic RBAC
Secure Context-sensitive Authorization [Minami and Kotz]
•
•
Distributed Proof
Test Case Generation
Trust frameworks
•
•
SECURE project
•
•
Dynamic notion of trust
Trust evolution based on interaction history
Reputation frameworks
Introduction – Solution – System – Analysis and Testing –
Related Work
– Conclusion
56
Future Work



Enhancements to the negotiation protocol
•
•
•
Other heuristics: expected time to finish, partial
ordering based on privacy and trust
Multi-party collective negotiation
Avoiding DoS attacks
Policy Manager
•
•
Running on resource-constrained devices
Porting to other middleware; e.g., GAIA
User Interaction
•
•
•
More control and feedback
Post-negotiation analysis
User-friendly policies
Introduction – Solution – System – Analysis and Testing – Related Work –
Conclusion
57
Conclusion






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





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 7th Annual IEEE International Conference on Pervasive
Computing and Communications (PerCom 2009).
Kevin Eustice, Leonard Kleinrock, Shane Markstrum, Gerald Popek,
Venkatraman Ramakrishna, Peter Reiher, “Enabling Secure Ubiquitous
Interactions,” In the Proceedings of the 1st 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, "nan0sphere: Location-Driven Fiction for Groups of
Users," In the Proceedings of the 12th International Conference on HumanComputer 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) YES
OFFER:
OFFER:
OFFER:
OFFER:
(4)
(2) YES
YES
(5)
(1) YES
[Result]
NO
(3) NO
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)you
Upgrade
Kernel
REQUEST
(Counter):
(1) Are
running
Ubuntu?
(3) v2.6.20 or higher?
Introduction – Solution –
System
– Analysis and Testing – Related Work – Conclusion
60
Case Study: Interactive Narrative


Team-, location- and actiondriven fiction deployed in UCLA
Purposes of negotiation
•
•
•

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(px6).
voucher(ht).
type(zp,bw).
voucher(vk).
printerName(pjf).
disp(l).
group(py,acm).
tim(gh).
brand(o,hp7100).
parentName(htm).
possess(diskSpace,0).
displayName(ck).
directory(ec,v).
file(fi1).
type(xz1,color).
voucher(c).
obey(X,open) :- printer(VAR),displayName(X, VAR001723).
accessInfo(X,(tim(VAR01213))) :- possess(X,
VAR0683),voucher(VAR0683),type(VAR0683, VAR1684).
access(X,diskSpace,VAR) :- childName(X, VAR023638).
obey(X,run) :- voucher(VAR),type(VAR,VAR1),possess(X, diskSpace, VAR1610).
obey(X,open) :- printer(VAR),memberIn(X).
obey(X,open) :- printer(VAR),childName(X, VAR023592).
accessInfo(X,(tim(VAR01213))) :- possess(X, diskSpace, VAR1573).
accessInfo(X,(tim(VAR01011))) :- action(X, order, open,
VAR0554),printer(VAR0554).
accessInfo(X,(childName(VAR023))) :- memberIn(X).
obey(X,open) :- printer(VAR),possess(X, diskSpace, VAR1481).
accessInfo(X,(childName(VAR023))) :- displayName(X, VAR001382).
access(X,VAR) :- voucher(VAR),type(VAR,VAR1),childName(X, VAR023354).
obey(X,run) :- voucher(VAR),type(VAR,VAR1),action(X, order, open,
VAR0144),printer(VAR0144).
Sample Goals
possess(VAR),door(VAR)
action(order,play,VAR),door(VAR),directory(VAR,VAR1)
action(order,closePort,VAR),door(VAR),type(VAR,VAR1)
action(order,prohibit,VAR),printer(VAR),brand(VAR,VAR1)