a review of trust management, security and privacy policy languages juri luca de coi l3s research...

A Review of Trust Management, Security

and Privacy Policy Languages

Juri Luca De CoiL3S Research Center & Hannover University

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

Daniel Olmedilla 27 Jul. 2008 2

The addressed scenario

Basic scenario1. Two parties2. A party P1 protects resources/services3. The other party P2 requests to access

such resources/services More advanced scenario

4. In order to allow P2 to access its resources/services P1 requests to access P2‘s resources/services

5. P2 protects its resources/services


Outline

A bit of history

Comparison criteria

Actual comparison

Conclusions


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

User1

...

Userm

Right1

...

Rightn

Table


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 requester‘s 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


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 requester‘s role

Why not simply processing the requests according to the requester‘s properties?


Outline

A bit of history

Comparison criteria

Actual comparison

Conclusions


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


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


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


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


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


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


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 party‘s decision

A PL must provide the ability to delegate authorization decisions


Comparison criteria: Policy evaluation (I)

Basic scenario1. Two parties2. A party P1 protects resources/services3. The other party P2 requests to access

such resources/services More advanced scenario

4. In oder to allow P2 to access its resources/services P1 requests to access P2‘s resources/services

5. P2 protects its resources/services

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

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


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 that1. the evaluation consists of different steps2. 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

3. the evaluation is made at each peer’s according to the currently available policies

Negotiation


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”


Comparison criteria: Policy engine decision

Under an abstract point of view a policy’s evaluation is either successful or not

successful the result of a policy‘s 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 user‘s point of view a boolean and generic error messages do not

help especially in case of failure, explanation must

be provided


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 XACML’s extension mechanism in order not to waste its standard combining algorithm


Outline

A bit of history

Comparison criteria

Actual comparison

Conclusions


Actual comparison

Cassandra

EPAL KAoS PeerTrust

Ponder Protune PSPL Rei RT TPL WSPL XACML

Well-defined semanti

cs

Yes Yes Yes Yes No Yes Yes Yes Yes No No No

Monotonicity

Yes - Yes Yes - Yes Yes Yes Yes No - -

Underlying

formalism

Constraint

DATALOG

Predicate logic

without quantifi

ers

Description

logics

Constraint

DATALOG

Object-oriente

d paradig

m

Logic programming

Logic programming

Deontic logic, Logic

programming, Descript

ion logics

Constraint

DATALOG

- - -

Action executi

on

Yes (side effect free)

Yes No Yes (only

sending evidenc

es)

Yes (access

to system

properties)

Yes Yes (only

sending evidenc

es)

No No No Yes Yes

Delegation

Yes No No Yes Yes Yes No Yes Yes (RTD)

No No No


Cassandra

EPAL KAoS PeerTrust

Ponder Protune

PSPL Rei RT TPL WSPL XACML

Type of evaluat

ion

Distributed

policies, local

evaluation

Local Local Distributed

Local Distributed

Distributed

Distributed

policies, local

evaluation

Local Local Distributed

policies, local

evaluation

Distributed

policies, local

evaluation

Evidences

Credentials

No No Credentials,

Declarations

_ Credentials,

Declarations

Credentials,

Declarations

- Credentials

Credentials

No No

Negotiation

Yes No No Yes No Yes Yes No No Yes No (policy

matching

supported)

No

Result format

A/D and a set of

constraints

A/D, scope error, polic

y error

A/D A/D A/D Explanations

A/D A/D A/D A/D A/D, not applicable

, indeterminate

A/D, not

applicable, indeterminat

e

Extensibility

Yes Yes Yes Yes Yes Yes No Yes No No No Yes


Outline

A bit of history

Comparison criteria

Actual comparison

Conclusions


Conclusions

There seem to be two trends standard-oriented languages

provide a stable 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


Thanks!

Questions?

[email protected]

a review of trust management, security and privacy policy languages juri luca de coi l3s research...

Documents

daniel olmedilla

resourcesservices slide

rolebased authorization

properties authorization

portugal slide

authorization process

requesters role rolebased

propertybased authorization