1. A Review of Trust Management, Security and Privacy Policy Languages Juri Luca De Coi L3S Research Center & Hannover University A Review of Trust Management, Security and Privacy Policy Languages 27 July.2008, Porto, Portugal

2. Daniel Olmedilla 27 Jul. 20082 The addressed scenario Basic scenario 1.Two parties 2.A party P1 protects resources/services 3.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

3. Daniel Olmedilla 27 Jul. 20083 Outline A bit of history Comparison criteria Actual comparison Conclusions

4. Daniel Olmedilla 27 Jul. 20084 Outline A bit of history Comparison criteria Actual comparison Conclusions

5. Daniel Olmedilla 27 Jul. 20085 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 User 1... User m Right 1... Right n Table

6. Daniel Olmedilla 27 Jul. 20086 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

7. Daniel Olmedilla 27 Jul. 20087 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?

8. Daniel Olmedilla 27 Jul. 20088 Outline A bit of history Comparison criteria Actual comparison Conclusions

9. Daniel Olmedilla 27 Jul. 20089 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

10. Daniel Olmedilla 27 Jul. 200810 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

11. Daniel Olmedilla 27 Jul. 200811 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

12. Daniel Olmedilla 27 Jul. 200812 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

13. Daniel Olmedilla 27 Jul. 200813 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

14. Daniel Olmedilla 27 Jul. 200814 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

15. Daniel Olmedilla 27 Jul. 200815 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

16. Daniel Olmedilla 27 Jul. 200816 Comparison criteria: Policy evaluation (I) Basic scenario 1.Two parties 2.A party P1 protects resources/services 3.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?

17. Daniel Olmedilla 27 Jul. 200817 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 1.the evaluation consists of different steps 2.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

18. Daniel Olmedilla 27 Jul. 200818 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”

19. Daniel Olmedilla 27 Jul. 200819 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

20. Daniel Olmedilla 27 Jul. 200820 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

21. Daniel Olmedilla 27 Jul. 200821 Outline A bit of history Comparison criteria Actual comparison Conclusions

22. Daniel Olmedilla 27 Jul. 200822 Actual comparison Cassand ra EPALKAoS PeerTru st PonderProtunePSPLReiRTTPLWSPL XACM L Well- defined semanti cs Yes NoYes No Monoto nicity Yes- - No-- Underly ing formalis m Constrai nt DATALO G Predicat e logic without quantifi ers Descript ion logics Constrai nt DATALO G Object- oriente d paradig m Logic program ming Deontic logic, Logic program ming, Descript ion logics Constrai nt DATALO G --- Action executi on Yes (side effect free) YesNo Yes (only sending evidenc es) Yes (access to system properti es) Yes Yes (only sending evidenc es) No Yes Delegati on YesNo Yes NoYesYes (RT D ) No

23. Daniel Olmedilla 27 Jul. 200823 Cassan dra EPALKAoS PeerTru st Ponder Protun e PSPLReiRTTPLWSPLXACML Type of evaluati on Distribu ted policies, local evaluati on Local Distribu ted Local Distribu ted Distribu ted policies, local evaluati on Local Distribu ted policies, local evaluati on Evidenc es Credent ials No Credent ials, Declara tions _ - Credent ials No Negotia tion YesNo YesNoYes No Yes No (policy matchin g support ed) No Result format A/D and a set of constrai nts A/D, scope error, polic y error A/D Explana tions A/D A/D, not appli cable, indet ermin ate Extensi bility Yes NoYesNo Yes

24. Daniel Olmedilla 27 Jul. 200824 Outline A bit of history Comparison criteria Actual comparison Conclusions

25. Daniel Olmedilla 27 Jul. 200825 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

26. Daniel Olmedilla 27 Jul. 200826 Thanks! Questions? decoi@L3S.de