1. Rule based Trust management using RT – third lecture Sandro Etalle University of Twente & Eindhoven thanks to Ninghui Li - Purdue William H. Winsborough – University of Texas S. Antonio. The DTM team of the UT (Marcin, Jeroen, Jerry). And the many people I’ve taken ideas from for this lecture (Winslett, Li, Seamons…)

2. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 2 Summary: A, B, D: principals r, r1, r2: role names A.r: a role (a principal + a role name) Four types of credentials:  A.r  D Role A.r contains principal D as a member  A.r  B.r 1 A.r contains role B.r 1 as a subset  A.r  A.r 1.r 2 A.r  B.r 2 for each B in A.r 1  A.r  A 1.r 1  A 2.r 2 A.r contains the intersection

3. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 3 Example: find the semantics Alice.s  Alice.u.v Alice.u  Bob Bob.v  Charlie Bob.v  Charlie.s What is the semantics?

4. Back to expressivity issues

5. RT0 limitations attributes (parameters) threshold separation of duty FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 5

6. Attributes (parameters) How can you make clear that Alice is the manager of Sandro and Bob is the manager of Eve.  FC.managerof(Sandro) <- Alice.  FC.managerof(Eve) <- Bob. Extends to Rules  FC.evaluatorof(?X) <- FC.managerof(?X). These are defined in RT1  RT1 has the concept of constraints and of domains for variables.  Important: study the syntax of RT1 FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 6

7. Additional Dialects Logical Sets (RT2)  skip it Threshold and Separation of duties (RTT)  check this out Delegation of role activation (RTD)  skip it I expect students to be able to say if a given policy can be expressed in RT0 and/or RT1 and if not, why. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 7

8. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 8 A personal view on negation in TM. Negation is good provided that  It is always in a context GOOD: all doctors that don’t have a specialty BAD: all non-doctors.  The negated predicate should rely on a definition we can “count on” Eg: FC.acc  FC.acc2 – FC.buyer FC should be able to tell who populates FC.buyer without having to beg around for credentials. See paper by Czenko et. al  (yes, I confess, I am one of the authors).

9. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 9 Non-monotonicity In the Flexible Company FC, a buyer may not be an accountant. How do we do this?

10. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 10 First way of solving this Use negation in the policies  FC.acc  FC.acc2 – FC.buyer When is Alice a member of FC.acc?  If Alice is a member of FC.acc2  AND Alice is NOT a member of FC.buyer But how do we determine that Alice is NOT a member of FC.buyer?  The easy way: if Alice is not in [[FC.buyer]] We are making a nonmonotonic inference.  What is nonmonotonicity?  What is the problem with nonmonotonicity?

11. Monotonic vs nonmonotonic A monotonic system satisfies the following  For each A, B.r, P and P'  If A is a member of [[B.r]] in policy P  and P' contains P  Then A is a member of [[B.r]] also in P' RT0 is monotonic But if we introduce negation it is not monotonic any longer Exercise: find an example of this FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 11

12. Why do we need monotonicity? Because in TM  Peers may not be available  Peers may withhold some information If you can't discover a credential  In a monotonic system the worst it can happen is that you do not manage to deduce something that is right  In a non-monotonic system you could make a wrong deduction This is because the absence of a credential is interpreted as "presence of negative information" It is a form of negation-as-failure FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 12

13. How do you solve the problem? You have to make sure that you are able to discover all the credentials of the policy that may occur "under negation". This prevents you from making wrong inferences. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 13

14. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 14 A second way of solving this Using an integrity constraint. FC.log ⊒ FC.buyer  FC.accountant Need a mechanism to monitor it. External to the RT system.  See Etalle & Winsborough…

15. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 15 Why Integrity Constraints Policies do change: P  P 1 ...  P n A principal controls only a portion of the policy  Statements may be added or removed by other principals  nowadays: trusted principals give no feedback to the trusting ones Delegating trust implies an understanding between principals,  nowadays: not formalized Trusted principals need assistance in understanding global impact of delegations, revocations  Who could get access to what? (Safety) Assessing exposure  Who could be denied? (Availability) Ensuring applications have authorizations needed for correct operation

16. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 16 Problem Instances “No-one should ever be both a buyer and an accountant”  Mutual Exclusion “Welders of BOVAG-accredited workshops should be fellows of the British Institute of Welding”  Containment “Every employee should have access to the WLAN network”  Containment, Availability

17. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 17 Integrity Constraints: General Form General: L.l ⊒ R.r  L.l ⊒ R.r holds in P iff [[L.l]] P  [[R.r]] P  L.l and R.r may be sets and intersections of roles Special cases  Membership: A.r ⊒ { D 1, …, D n }  Boundedness: { D 1, …, D n } ⊒ A.r  expressiveness is limited (it is a universal formula) but we can express all safety properties of [LWM03]  counterexample: at least a manager should have access to the DB

18. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 18 Exercise: find the right constraint: buyers and accountants should be disjoint every employee should have access to the WLAN network welders of BOVAG-accredited workshops should be fellows of the British Institute of Welding Bovag.welder  Bovag.accr.welder Bovag.accr  PietersWorkshop PietersWorkshop.welder  Pieter

19. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 19 Answers buyers and accountants should be disjoint   ⊒ A.buyer  A.accountant every employee should have access to the WLAN network  WLAN.access ⊒ UT.employee welders of BOVAG-accredited workshops should be fellows of the British Institute of Welding Bovag.welder  Bovag.accr.welder Bovag.accr  PietersWorkshop PietersWorkshop.welder  Pieter  BIW.fellow ⊒ Bovag.welder

20. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 20 The technical problem (a taste of research) P  P1 ...  Pn: policy change L.l ⊒ R.r: a constraint Need a (minimal) mechanism such that  IF L.l ⊒ R.r does not hold in Pi  THEN a warning is fired  without checking L.l ⊒ R.r each time a credential is added/removed How: by monitoring when some credentials are added or removed

21. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 21 The solution in short P – policy, Q = L.l ⊒ R.r – IC Define 2 set of roles:  G = roles R.r depends on  S = roles satisfying [[L.l]] P|S  [[R.r]] P Theorem: Let P  P1 ...  Pn IF  P satisfies Q  no credential S is removed  no credential for G is added THEN  Pn satisfies Q  G and S don’t have to be recomputed

22. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 22 The method P – policy, Q = L.l ⊒ R.r: constraint CHECKING FIRST, compute [[R.r]] P  here G is computed “for free” THEN, for each X  [[R.r]] P, check that X  [[L.l]]  here (one of the) S is computed “for free” MONITORING Let P  P1 ...  Pn IF  no credential for S is removed  no credential for G is added Then  OK Otherwise  Check Q again, and  Recompute G and S (even if Q still holds) To monitor this we need the cooperation of other principals

23. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 23 Conclusions Integrity constraints:  tool to control a TM system. Monitoring requires the cooperation of trusted principals Trust management becomes a two way process  from the trusting to the trusted  and vice-versa

24. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 24 Conclusions for the whole RT part Context:  2 or more parties in an open system.  parties are not in the same security domain. Goal  establish trust between parties to exchange information and services (access control) Constraint  access control decision is made NOT according to the party identity BUT according to the credentials it has

25. FOSAD 2006 summer schoolEtalle: Rule Based Trust Management with RT 25 Open problems Analysis  safety analysis we are now working with Spin in RT0, for RTC (with constraints) nothing is available  of negotiations protocols w.r.t. the TM goals. Integration with other systems  e.g. privacy protection location-dependent policies  ambient calculi? DRM Semantics is not correct when considering:  chain discovery  negotiations is not modular  certainly possible to improve this using previous work on omega-semantics. Types