On the Modeling and Analysis of Obligations

1. On the Modeling and Analysis of Obligations Keith Irwin, Ting Yu (North Carolina State University) William H. Winsborough (University of Texas at San Antonio) Presenter: Zhenhua Liu Date: April 22nd, 2009

2. Overview • Related Works • Motivation • Contributions • A meta-model for obligations • State transition • Example of obligation system • Definition of Accountable State • AConcrete Model • Basic Algorithms • Conclusion & Future Works

3. Related Works P1 • Traditional security policies largely focus on the specification and management of access control requirements. ( who can access what objects during which period) • Obligation requirements are involved nowadays (i.e. Subscriber is obliged to pay fee before a certain deadline)

4. Related Works P2 Current policy languages that supports the specification of obligation in security policies: • XACML and KAoS (limited model to describe obl) • Ponder and Rei (time constraints, deadline) • Heimdall (keeps track of pending obl) • Sailer and Morciniec( 3rd party to monitor obl)

5. Related Works P3 • Bettini ( choose appropriate policy rules and extended their policy model to handle obl violations) • Above-mentioned works focus on specification and monitoring of obligation, • This paper formally defines secure state, complexity of checking whether current state is secure (complimentary)

6. Related Works P4 Current works that analyze systems with obligations to determine whether subjects have sufficient right to fulfill their obligations • Firozabadi( static allotments of resources) • Kamoda (unable to model when user actions can change the state of the system)

7. Related Works P5 Current works that has been done on access control policies. • Determining accountable state is analogous to but more complicated than Complicance checking in access control( e.g. whether an action should be allowed based on an access control policies)

8. Motivation • Although several security policy languages have been proposed for describing obligation requirements, • Some questions like how to definesecure states and how to ensure the security of a system, have not yet been adequately investigated

9. Contributions • Propose a formal metamodel to capture a system and its possible states. • Give a formal definition of secure states for obligation management. • Study the problem of checking whether a state is accountable • Study the accountability problem in the context of a authorization system with obligations

10. Properties of Obligations • Positive Obligation: Requirement for a subject to take some action at some time in the future • Negative Obligation: Requirement for a subject NOT to take some action at some time in the future Unenforcable: any action cannot be forced by a system Monitorable: be able to monitor the status of an obligation.

11. A Metamodel for systems with Obligations • Model an obligation as a tuple obj(s, a, O, [ts, te]) s is a subject, a is an action, [ts, te] is atime window during which s is obliged to take action a, O is finite sequence of zero or more objects on which the action must be performed

12. Four states of obj(s, a, O, [ts, te]) • Invalid: if te is already passed when it is assigned • Fulfilled : if an obligation has been assigned and its action has been carried out during time window [ts, te] • Violated : if an obligation has been assigned, has not been fulfilled, and is not invalid, but te has passed • Pending: if an obligation is not invalid but has not yet become fulfilled or violated, then it is pending

13. State Transition Assumption: • discrete system time • each action can be finished in a single clock tick For instance: the state of a system at time t0 is st0 , and Alice takes an action at t0 , This change will not change. Instead the state at time t0+1 will be affected by Alice’s action.

14. Defining Obligation-abiding transition

15. An Example of Obligation System Policy Description: 1. after collecting submitted papers, the program chair of a conference assigns papers to reviewers 2. Once the assignment is done, each reviewer is obliged to submit their reviews by a certain deadline 3. If a reviewer submits a review for a paper, she’s obliged to attend the discussion of the paper, which decides whether the paper should be accepted

16. An Example of Obligation System How to use this meta-model to represent a Simple Conference Reviewing System • Subjects s are the registered users in the system • Objects o are submitted papers • Actions a allowed(assigning papers to reviewers, submitting a review and joining discussion of a paper • The σ-proportion of the system state represents attributes of subjects and objects.

17. Example of policy description of the system using proposed meta-model

18. Suppose on 06/01/06 the program chair assigns Alice to review papers p1, p2 and p3. Obl1= obl( Alice, submit_review(Alice,p1), [06/01/06, 07/15/06]) Obl2= obl( Alice, submit_review(Alice,p2), [06/01/06, 07/15/06]) Obl3= obl( Alice, submit_review(Alice,p3), [06/01/06, 07/15/06]) Add pending obligation into the system

19. Security Goals In Systems with Obligations • Goal To make sure that a system always stays in secure states and never transits into insecure states. • Accountability Find out whose fault it is when it’s possible that some obligation go unfulfilled, rather than require that it is impossible for obligation to be violated

20. Defining Accountable states • Different interpretation of Obligations (if everybody else fulfills their obligations) • Strongly accountable System guarantees that subject take action a at any time between [ts, te] • Weakly accountable Subject can at least take action a at the end point te • Uncommon System ensures only that there exists some time within the frame when the user will be able to fulfill his obligation

21. Defining Strongly Accountable State

22. Defining Weakly Accountable state

23. The Accountability Problem • Given a state in a system , how to determine whether it is accountable? • Using Turing Machine to do a reduction of the halting problem to the accountability problem.

24. Three conditions of obligation sytem • No cascading obligations the action to fulfill an obligation doesn’t incur further obligations • Monotonity if the condition on a policy is true for a subject, it will remain true in all future states • Commutative actions the execution order of two actions don’t matter

25. Three Theorems of Accountability Problem

26. A Concrete Model • Add some restrictions to the proposed meta-model to make accountability problem tractable:

27. Basic Algorithm Assumption • An current accountable state stcur=<tcur, Mcur, Bcur> • a obligation b=<b.s, b.a, b.ts,b.te> • Positive test Purpose determine whether we should add a new obligation b in order to keep the system in an accountable state

28. Basic Algorithm • Check Rights • Check effect of b on obl it overlaps. • Check effect of b on later obligations. If (found overlapping revoke action) test cannot be guaranteed else if (privilege exists in the stcur) if (there is prior revoke action) pick a br to maximize br.te else test can be guranteed else if( privilege does not exist in stcur) if ( exists some grant obligation for tested permission) pick some bg so as to mamiize bg.ts else the test cannot be guaranteed If (b revokes or grants a right which could cause the condition of an obligation it overlaps to be false) the state is not accountable The obl b either grants or revokes some right. Oligation which depend on the presence or absence of this rigt need to be considered. To check them, we reat step 1 of

29. Conclusion & Future works • Formally investigates the relationship between obligation and security policies • Identify more properties of obligation policies • Support commonly available features in today’s access control system • Extend the meta-model to support event-triggered obligation