A Review of Trust Management, Security and Privacy Policy Languages

1
A Review of Trust Management, Security and
Privacy Policy Languages
A Review of Trust Management, Security and
Privacy Policy Languages27 July.2008, Porto,
Portugal

• Juri Luca De Coi and Daniel Olmedilla
• L3S Research Center Hannover University

2
The addressed scenario

• Basic scenario
• Two parties
• A party P1 protects resources/services
• The other party P2 requests to access such
  resources/services
• More advanced scenario
• In order to allow P2 to access its
  resources/services P1 requests to access P2s
  resources/services
• P2 protects its resources/services

3
Outline

• A bit of history
• Considered policy languages (PLs)
• Comparison criteria
• Actual comparison
• Conclusions

4
Outline

• A bit of history
• Considered policy languages (PLs)
• Comparison criteria
• Actual comparison
• Conclusions

5
A bit of history Identity-based authorization
Identity-based authorization

• each user has a set of rights
• a table maps users to rights
• Drawbacks
• users have to be known in advance Þ
• not suitable for an open environment

Table
User1
Right1
...
...
Userm
Rightn
6
A bit of history Role-based authorization

• The authorization process is split in two steps
• Authentication the requesting party is assigned
  to some role according to its properties
• Authorization the request is processed according
  to the requesters role
• Role-based PLs only support one single step
• Authentication how to assign requesters to roles
• Authorization how to describe which
  resources/services a role can access

7
A bit of history Property-based authorization

• The authorization process is split in two steps
• Authentication the requesting party is assigned
  to some role according to its properties
• Authorization the request is processed according
  to the requesters role
• Why not simply processing the requests according
  to the requesters properties?

8
A bit of history Caveat

• The border between types of PLs is fuzzy
• Some PLs (e.g., RT and Cassandra) support
  parametrized roles
• Roles are parametrized according to the
  requesters properties

9
Outline

• A bit of history
• Considered policy languages (PLs)
• Comparison criteria
• Actual comparison
• Conclusions

10
Considered policy languages (I)

• Just few words per PL
• More features will be introduced lateron in the
  talk
• Cf. paper for more details about each PL

11
Considered policy languages (II)

• TPL (Trust Policy Language)
• One of the first relevant (role-based) PLs
• Some features are out-of-date
• Mentioned because of historical reasons
• Ponder
• Well-known (role-based) PL
• Recently Ponder2 has been released
• It goes its own way (w.r.t. role-based and non
  role-based PLs)

12
Considered policy languages (III)

• RT (Role-based Trust-management framework)
• A first step toward property-based PLs
• Introduces the concept of parametrized role
• Available in different flavors
• Cassandra
• A further step toward property-based PLs
• Proposed in order to overcome some drawbacks of RT

13
Considered policy languages (IV)

• EPAL (Enterprise Privacy Authorization Language)
• One of the first relevant property-based PLs
• Paved the way to XACML
• XACML (eXtensible Access Control Markup Language)
• Probably the most widely known PL
• Standard in the field of PLs
• ? supports well-known (i.e., not advanced)
  requirements
• WSPL (Web Services Policy Language)
• An instantiation of XACML for Web Services

14
Considered policy languages (V)

• KAoS
• Targets software agent applications
• dynamic runtime policy changes need to be
  supported
• Only PL based on Description Logic
• Rei
• Well-known in the research community
• Originally meant to support pervasive computing
  applications

15
Considered policy languages (VI)

• PeerTrust
• First PL supporting negotiations
• PSPL (Portfolio and Service Protection Language)
• Supports negotiations
• First PL supporting declarations
• Protune
• Supports negotiations
• Supports declarations
• First PL supporting explanations

16
Outline

• A bit of history
• Considered policy languages (PLs)
• Comparison criteria
• Actual comparison
• Conclusions

17
Comparison criteria Introduction

• Other comparisons among PLs are available in the
  literature (? paper)
• Most comparisons are pretty old
• The criteria they used are out-of-date
• Do not consider later advancements in the
  research field
• Most comparisons focus on specific aspects/PLs
• No one is as broad as this one

18
Comparison criteria Well-defined semantics

• Well-defined semantics
• It must be known in advance how the policy will
  be enforced
• The meaning of a policy written in a language is
  independent of its particular implementation
• Logical formalisms (like Description Logic,
  Predicate Logic and Logic Programming) have a
  mathematically defined semantics
• we assume that PLs based on such formalisms have
  a well-defined semantics

19
Comparison criteria Underlying formalism

• Underlying formalism
• No underlying formalism (Ponder, TPL, WSPL,
  XACML)
• Logic Programming (Protune, PSPL, Rei) or a
  subset of it (DATALOG Cassandra, PeerTrust, RT)
• Predicate logic without quantifiers (EPAL)
• Description logic (KAoS)
• The underlying formalism influences the
  properties of the PL
• Logic Programming no existential quantification,
  non-monotonic reasoning
• Description logic no variables, conflicting
  information

20
Comparison criteria Monotonicity

• Monotonicity
• We do not mean monotonic reasoning
• The more information is released, the more
  authorizations should be provided
• Example a non-monotonic policy
• Access to some resource is provided if the
  requester does NOT have some credential
• There is no way to check whether the requester
  does not have the credential or did not want to
  send it
• TPL a non-monotonic policy language
• Assumption a credential does not exist if it is
  not in the local repository

21
Comparison criteria Condition expressiveness

• A policy states which subject(s) can(not) execute
  which action(s) on which object(s)
• A policy may
• require to explicitly identify subject, action
  and object
• e.g., subject Alice can perform action download
  on resource myFile.txt
• allow to describe which properties they must have
• e.g., all subjects having a credential issued by
  VISA can perform all read-only actions on all
  public resources
• Property-based descriptions are more compact
• Not all PLs allow to specify properties for
  subject, action and object

22
Comparison criteria Action execution

• Action execution
• Authorization decisions are not necessarily
  performed on the basis of a static knowledge base
• The authorization process may require that some
  involved party performs some action
• credential deliver (originally the only
  considered action)
• access to system properties (e.g., time)
• access to databases or file systems

23
Comparison criteria Delegation

• Delegation
• A basic requirement in authorization scenarios
• addressed even by the first PLs
• Sometimes a party could
• be unable to take (part of) an authorization
  decision
• know some third party able to take it
• trust the third partys decision
• A PL must provide the ability to delegate
  authorization decisions

24
Comparison criteria Policy evaluation (I)

• The policy is defined locally
• The policy evaluation takes place locally

• Basic scenario
• Two parties
• A party P1 protects resources/services
• The other party P2 requests to access such
  resources/services
• More advanced scenario
• In oder to allow P2 to access its
  resources/services P1 requests to access P2s
  resources/services
• P2 protects its resources/services

• The policy is not defined locally
• The policy evaluation takes place locally?

25
Comparison criteria Policy evaluation (II)

• The policy evaluation can take place locally only
  if the policies are public
• In some real-world scenarios it is desirable
  keeping (part of) the policies private
• A distributed evaluation is needed such that
• the evaluation consists of different steps
• at each step one party sends the other one the
  part of its own policy that at that very moment
  the other party is allowed to receive
• the evaluation is made at each peers according
  to the currently available policies

Trust negotiation
26
Comparison criteria Evidences

• Traditionally it was assumed that information
  exchanged between parties was digitally signed
  (credentials)
• Not always information needs to be digitally
  signed
• the credit card number you provide in order to
  finalize an online purchase is not digitally
  signed
• PLs must support credentials as well as
  declarations
• both are referred to as evidences

27
Comparison criteria Policy engine decision

• Under an abstract point of view
• a policys evaluation is either successful or not
  successful
• the result of a policys evaluation can be
  represented as a boolean
• Under an engineering point of view
• error messages must be foreseen in order to cope
  with exceptional situations
• The users point of view
• a boolean and generic error messages do not help
• especially in case of failure, explanation must
  be provided

28
Comparison criteria Extensibility

• Many PLs provide some means to allow extensions
• inheritance in Ponder
• support to new datatypes, functions and combining
  algorithms in XACML
• ontologies in KAoS, Rei and Protune
• constraint domains in Cassandra
• An exception RT
• new requirements were addressed by releasing new
  versions of the language
• Another exception WSPL
• gives up XACMLs extension mechanism in order not
  to waste its standard combining algorithm

29
Outline

• A bit of history
• Considered policy languages (PLs)
• Comparison criteria
• Actual comparison
• Conclusions

30
Actual comparison
31
(No Transcript)
32
Outline

• A bit of history
• Considered policy languages (PLs)
• Comparison criteria
• Actual comparison
• Conclusions

33
Conclusions

• There seem to be two trends
• standard-oriented languages
• provide a solid solution for well-known
  requirements
• EPAL, WSPL, XACML
• research-oriented languages
• support more advanced features
• KAoS, Rei, Cassandra, PeerTrust, PSPL, Protune
• Somehow in between
• Ponder, RT, TPL

34
Thanks!

• Questions?
• decoi_at_L3S.de