specification of usage control requirement
TRANSCRIPT
Table of Contents
1. Usage Control?
2. Obligation Specification Language (OSL)
3. Brief introduction to another Policy Language : Ponder.
4. Comparison between OSL and Ponder.
5. Analysis: compare OSL to other security languages
6. Conclusion.
7. Questions.
Concerns for data distribution
Once data is distributed, control is limited.
Concerns for Data Providers:
Privacy,
Intellectual Property,
Data Security,
Data Sender and Receiver need to agree to conditions.
Conditions for data distribution
Data distribution on two grounds
Conditions that should already satisfy before data is given to a
receiver : Provisions
and
Conditions on future use of data : Obligations
Usage Control deals with Obligations
What is Usage Control?
Usage Control deals with
who and how,
must or must not,
allowed or not allowed,
to use the data after distribution.
Encompasses
Specification of conditions and control enforcement
mechanisms
Usage control requirements
Existing literature on notions of
Usage Control.
But,
Separately studied,
Closed source implementations,
Not defined precisely,
Lack of holistic system model for Usage Control.
Focus
Specification of conditions
Not into: control enforcement mechanisms
Languages Reviewed
Usage Control Specific:Obligation Specification Language (OSL)
Another Policy Language
Policy
Obligation Specification Language does:
Analysis of policies
If set of mechanisms enforces a given policy?Is a policy free of contradiction?
General purpose specification language for Usage Control
Combine "must" and "may" modalityExample: Allows DRM mechanisms for enforcing privacy policies
Interoperability between different DRM Mechanisms
and give a formal semantics to these languages
Obligation Specification Language
First order linear temporal logic
Formalized in 'Z'
OSL : Time Steps and Traces
Policies act upon a long period of time, which is divided into
discrete time portions called time steps.
A trace is the combination of these time steps as a whole. At
each time step of a trace, multiple events can happen.
OSL : Events
EventDecl Example:
{
(play, usage, {(object, ObjID), (device, DevID)}),
(backup, usage, {(object, ObjID), (device, DevID)}),
}
● Used interchangeably with action.
● Has (name, type {parameter set})
● Event type can be either usage (usage of data) or other
(signalling or messaging or similar events)
● Parameters specify extra details about the event (Eg: data
item the event is performed on, etc)
OSL : Indexed Events
An event can be as long as one or more TimeSteps.
Efst
- Indexed event with index start
Eall
- All indexed events with index ongoing
1st
start Efst
Eall
ongoing
ongoing
ongoing
ongoing
...
OSL : Time Steps and Traces
(Alice, repmax(5, Efst
((play, {(object, mov)}))))mov can be played for 5 times at max
(Alice, repmax(5, Eall
((play, {(object, mov)}))))mov must not be played more than 5 time stepsNote the difference with the first example
OSL : Obligation formula
{
(Alice, permitonlyevname({play, backup}, {(object, mov)})),
(Alice, repmax(5, Eall
((play, {(object, mov)})))),
(Alice, repmax(1, Efst
((backup, {(object, mov)})))),
}
Each line is an obligation formula ( SubjectID x Φ )
Obligation formula are of two different forms:
1. Action Requirements (Mandatory Actions)
2. Usage Restrictions (Prohibiting Conditions)
OSL : Conditions in obligation formula
Circumstances under which the usage restrictions or action
requirements apply.
Logical Operators: not(x), and(x,y), or(x,y), implies(x,y)
Eg: (Alice, not( Efst
( (play, {Object, song.mp3}) ) ))
Temporal Operators: until(x,y), after(n,x), during(n,x), within(n,x)
Eg: (Alice, after( 5, Efst
(...) ) )
Cardinality Operators: replim(i,m,n,x), repuntil(n,x,y), repmax(n,x)
Eg: (Alice, replim(20, 5, 30, Efst
((playCommercial , {(stream, s)}))) )
Permit Operators: permitonlyevname(es,ps), permitonlyparam(pv,pn,es,ps)
Eg: (Alice, permitonlyevname({play, backup}, {(object, mov)}))
OSL : Operators (Informal Description)
OSL : Syntax and Example
OSLPolicy = {EventDecl} x {OblFormula}
OblFormula = SubjectID x ΦExample OSLPolicy({
(play, usage, {(object, ObjID), (device, DevID)}),
(backup, usage, {(object, ObjID), (device, DevID)}),
}, {
(Alice, permitonlyevname({play, backup}, {(object, mov)})),
(Alice, repmax(5, Eall
((play, {(object, mov)})))),
(Alice, repmax(1, Efst
((backup, {(object, mov)})))),
}
● OSL supports must and may modalities.
● OSL more expressive than other RELs like XrML and ODRL
● Translation from OSL to ODRL and viceversa done.
Why? Three main reasons:
1. Give semantics to XrML, ODRL or any other RELs.
2. Intermediate translation language between RELs.
3. Utilize enforcement mechanisms existing for RELs.
OSL : Translation from OSL to RELs
● A subset of Open Digital Rights Language (ODRL) called
ODRLcompact (ODRLc) chosen that does not include
concepts outside the scope of OSL.
● ODRLc specify rights which are of may modality.
● All ODRLc licenses can be expressed in OSL.
OSL : Translation ODRLc to OSL
● Not all OSL expressions can be expressed in OSL.
● Difficult to identify which subset can be translated.
● Pragmatic approach : Pattern matching used
(subid, repmax(n, Efst
(ue))) to <count> expressions.
● Syntactic pattern matching requires obligations to be in an
implicitly defined canonical form. Slight variations will result
in a mismatch.
● Difficult and needs improvement.
OSL : Translation OSL to ODRLc
Ponder
October 2000
Strongly typed, Object Oriented Language.
Used for Policy Specification.
Policies does not clearly focus on Provisions and Obligations
Strong focus on Policy Expression, Management and Organization with Roles and Relationships.
Declarative language, leaves implementation for other programming languages.
1. Declare delegatable policies.
2. Support policies relating to large collection of objects,
possibly millions.
3. Composite policies that group basic policies according to
roles, organizational units, etc.
4. Analyze conflicting policies.
5. Simple extension of policies with Inheritance.
Problems addressed by Ponder
● A policy is collection of one or many rules.
● Policy is defined as methods in interface definition language.
Example:
Ponder : Policy definition
● Policy type is a template.
● A policy instance is derived from a Policy type, also can be
defined directly.
● Instance defines the real policy.
● Policy Type and Policy Instance are analogous to Class and
Object Instance in Object oriented languages.
Ponder : Policy type and instance
● Basic Policies
Contains only policy elements, no children policies.
○ Authorization Policies
○ Obligation Policies
○ Refrain Policies
○ Delegation Policies
● Composite Policies
Contains children policies. Main idea is organization.
○ Group, Roles, Relationships, Management Structures
Ponder : Policy Categorization
Specify actions that must be performed on a set of target objects
when an event occur.
Example
states that when Steven’s temperature exceeds 37 degrees,
nurse takes two actions: first she administers analgesics
followed by second manually recording his temperature.
Ponder : Obligation Policies
● Simplify specification and organization of policies from small to
large distributed systems.
● Provide a syntactic scope for child policies who share common
declarations.
Types
● Groups
● Roles
● Relationships
● Management Structures
Ponder : Composite Policies
Comparison of dedicated Usage Control Specification Language
(OSL) to a general Policy Language (Ponder) in terms of:
● Syntax and semantics consideration
● Implementation
● Policy organization
● Ability to describe temporal conditions
Discussion
OSL
Formalized in Z, well defined syntax and semantics. XML
representation available. Easy to understand.
Ponder
Well defined Syntax and Semantics. Not described on a Formal
Language. Object oriented and declarative in nature, supports
inheritance for re-use.
Discussion : Syntax and Semantics
OSL
Representation on abstract level. Event names, Parameters have
to be mapped to actual implementation. Pro - provide
generalization, con - Extra effort for mapping.
Ponder
Although being declarative, it models the actual system more
closely.
Discussion : Implementation
OSL
Less concerned about organization and management. Focus is
on expression of requirements than administration of policies.
Main focus - Usage Control.
Ponder
Contains a lot of policy and resource management tasks in its
specifications.
Discussion : Organization
OSL
Temporal conditions are one of the primary concerns as the
norm of time steps as well as temporal operators: until, after,
during along with other operators allow expressing complex
time based conditions.
Ponder
Contains Timer library that allows to specify time-point events,
repeated events based on duration and repeated events at
specific time-points. Lacks the norm of time-steps to perform
cardinal operations, eg: Movie can be viewed only 10 times.
Discussion : Work with Temporal Conditions
Conclusion
● Main challenge : Usage control covers huge scope, develop a
general purpose language that allows to express
requirements of this huge scope.
● Different approaches found in the languages under study.
● Different factors affect language adoption : ease of
expression, ease of implementation, generalization and
ability to adapt to changes.
● OSL looks to be highly focussed in Usage Control and future
developments should make it more feature rich, means
wider adoption by the industry.
Questions?
Take care of
● Data roles : Owners, Carriers, Consumers
● Network and Medium of data flow
● Data types : Physical Object, Digital Object, etc
● Restriction Types : Permission, Restrictions
● Restriction Mechanisms : Preventive control mechanisms vs
Observation mechanisms
● etc
More challenges
Examples
ODRL formalizationhttp://arxiv.org/pdf/cs.LO/0601085.pdf
ODRL and MPEG-21 Translationhttp://odrl.net/workshop2004/paper/odrl-polo-paper.pdf