[xacml] Agenda for Policy Subcommittee concall (Wednesday Mach 6,2002) (fwd)

[Pierangela Samarati <samarati@pinky.crema.unimi.it>]

Hi 

it bounced back,i am sending it again hoping it will go through

best
-p

---------- Forwarded message ----------
Date: Wed, 6 Mar 2002 16:25:45 +0100 (CET)
From: samarati@pinky.crema.unimi.it
Cc: xacml@lists.oasis-open.org
Subject: Agenda for Policy Subcommittee concall (Wednesday Mach 6, 2002)

Agenda for Policy Subcommittee concall (Wednesday Mach 6, 2002)
===============================================================

First of all apologies for having postponed the concall (also my mail
to the list bounced back and i found it out only next morning). 

Below is a description of my understanding of the issues we have to
decide. The objective is to try to have a summary view of what we have
been through w.r.t. policies, metapolicies, and rules and use it as a
basis for the discussion tonight (i do not have any proposal below, i
just tried to summarize the solutions that have been proposed with
their pros and cons). It is still not complete (metapolicies are
missing) and I might have certainly forgot something, but i hope it
will be useful for us at least to establish a path to go through and
take decisions on how to proceed.

Proposed agenda for tonight.

- Format of rules
- Format of policies
- Metapolicies
- Postconditions

It would be nice if we were to take some decisions on them (rather
than putting down the questions for the F2F) so to have a concrete
proposal to discuss at the F2F. 

I should apologize to Michiharu for having put post-conditions in the
agenda in the last two concalls and not having gone through
them. Problem is that we need to have the basics resolved before going
to post-conditions. Tonight we should be able to go over them (as
probably we should be getting a solutions for the other topics or
agree to put down the different approaches for a final decision next
monday at the F2F). 

Talk to you later 

best
-p


===============================================================

A SUMMARY OF ISSUES TO DISCUSS IN THE POLICY MODEL SUBCOMMITTEE

Let us start on the aspects on which everybody agrees. 
We all agree to have a target associating with a policy. A target
specifies for which subjects, actions, and resources a given policy is
intended. The reason for assuming a target is mostly `efficiency' as
policies `not relevant' for an access can be simply ignored in the
access control process.

POLICY (elementary)
------
The basic element for defining a policy is a rule. A rule is the
corresponding of traditional authorizations. Intuitively, a rule
translates each of the possible regulations that we may want to be
enforced (e.g., a person may read any record for which the person is
the designated patient).

RULE
-----
The rule is a boolean expression of predicates on attributes of
subject/resource/action that identifies to which subjects, resources,
actions, the rule applies. In principle, for clarity, the boolean
expressions could be separated into three different components:
- one for conditions on the subject
- one for conditions on the resource
- one for conditions on the actions.

The separation into the three different components has the advantage
of making the rules more readable. 

It has, however, the following disadvantages:

1) there are predicates that span the domains. For instance where
   should we put a predicate requesting equality between the user
   identifier of the request (subject attribute) and the owner of the
   resource (resource attribute)? A possible solution to this problem
   could be to predefine the fact that such conditions belong to the
   resource expression.

2) While the global boolean expression allows to combine subject's
   conditions and object's conditions in either AND or OR, the
   solution of having different expressions should assume one of this
   combinations (which would be AND, as it is typically done). For
   instance in the case of the global boolean expression I can say
   that a rule applies if ``subject expression OR object
   expression''. If I condider the expression independently I would
   have to specify two rules for stating the same authorizations.


Besides the conditions on the subject, resource, and action, the rule
can also have environment conditions (e.g., time of the request) or
other conditions (in case we want to support dynamic procedures).

The rule can also have associated post-conditions (ref. Michiharu)

POSITIVE VS. NEGATIVE?
----------------------

However expressed a rule wants to specify how an access should be
treated.

Next aspect to deal with is then whether the rule should specify only
permissions (meaning a rule specifies only what is to be allowed).
There have been several discussions on the list. At first, for
simplicity considerations it was decided to support permissions
only. Later on everybody seemed convinced that permissions only are
not enough and, in the model we should look at considering a negative
form also. Discussions have looked at two (mutually exclusive) ways of
representing rules not in positive forms

1) Permissions and denials.  
   
   Intuitively, rules can be of two kinds. Positive or
   negative. Positive rules (or permissions) state which accesses are
   to be granted. Negative rules (or denials) state which accesses are
   to be denied. 

   Negative rules are convenient in the specification but they
   introduce the problem of dealing with conflicts. 

   A simple policy that could be applied is the
   `denials-take-precedence' by which if there are both a permission
   and a denial for an access the access should be denied (or, more
   correctly, the policy should respond `no'). 

   The simple denials-take-precedence may not be enough. For instance,
   even in the simple model of Apache users can choose between two
   different ways of evaluating the combination of permissions and
   denials.  
   Therefore something more should be supported. 

   In previous discussions it seems that a good solution would be to
   possibly associated with each policy a metapolicy regulating how
   the rules in it should be evaluated. Intuitively, the statement
   `order....' of Apache would be a metapolicy, as it would be the
   `denials-take-precedence' principle.
   
   It is worth noting here that it is not clear whether we would be
   able to support some of the possible conflict resolution approaches
   that had been mentioned in the discussions. For instance,  one
   approach that was often mentioned is the
   `most-specific-take-precedence') which state that the rule that
   should prevail should be the one on the most specific
   resource. Intuitively, the rule of a user overrides the one of a
   group, the rule of a file overrides that of a directory. 
   The problem is that this approach works under the assumption that
   there are the defined hierarchies and that the rules are spcified
   on elements of such a hierarchy. By contrast our rules are not so
   simple and use generic boolean expressions so it is not clear
   whether the subject or the resource in a rule is more specific that
   that in another rule. 

2) Necessary vs. sufficient conditions

  An alternative approach of supporting a form of rule different from
  a permission is to distinguish between rules specify conditions that
  are sufficient (as far as the rule is concerned) for the access and
  conditions that are necessary for the access, i.e., access can be
  granted ONLY IF they are satisfied. Intuitively, the first type of
  rules (i.e., sufficient) are equivalent to the permissions
  above. The second type of rules represent an alternative way of
  expressing denials. For instance, suppose access to some files must
  be restricted to doctors. In option 1 above you would have specified
  a negative authorizations for NONdoctors. In this option you would
  specify a rule that says that access to the file can be granted ONLY
  IF the requestor is a doctor. Intuitively, ONLY IF rules combine in
  AND with themselves and with all the IF rules. 

  The advantage of this option is that is simple and expressive enough
  for many cases. It is however true that it is less expressive and
  flexible than option 1 since it predefines the way rules should be
  evaluated (intuitively, it corresponds to the support of
  denials-take-precedence). 


SETS VS. BOOLEAN EXPRESSIONS
----------------------------

However the rules are expressed another issue to solve is how rules
are put together to form a policy. Here two proposals have come out
from the discussions

1) A policy is a boolean combination of rules. This means that a
   policy for instance can say things like 

  Rule1 AND (Rule2 OR Rule3)

  Here my guess is that the semantics of such specifications are not
  clear (or at least is not clear to me). I will leave to others
  (Tim??) to say something more on this.

   [note/doubt: there are cases where constraints on access need
   indeed to be combined in AND. One example is restrictions on a
   specified at different level of granularity of a hierarchy where
   you impose that to access a resource somebody should be authorized
   for the access on all its ancestors, e.g., like in Unix you need to
   have the x on all directories to access a file. But i do not think
   supporting AND of rules would be proper to handle these cases].

2) A policy is a set of rules. Intuitively, here if all the rules are
   positive is like if they were considered in OR (it is sufficient
   that one rule is satisfied for the access to be granted). If rules
   can be negative then how the set should be evaluated depends on the
   metapolicy. If rules can be in ONLYIF format they are evaluated as
   discussed above. 


COMPOSITE POLICY
----------------

In its elemantary form a policy is composed of rules. It would be
useful to have policies defined based on other
policies. Non-elementary policies are defined on the basis of other
policies. In the discussions we have always assumed non-elementary
policies to be boolean expressions of policies. In other words, assume
each policy is assigned an identifier, than a non-elementary policy
could be defined as 

P = P1 AND (P2 OR P3)

The semantics of such a policy should be that P allows an access if P1
allows it AND if either P2 or P3 allow it. 

The semantics and the result of the AND and OR operators applied to
policy should be defined with reference to the values that a policy
can return. A policy can return value:
- Allow
- Deny
- I do not care

where the Deny can be returned because of a negative rule or also
because of the absence of a positive rule in a policy applying a
closed principle (i.e. whatever is not explicitely authorized should
be denied). We may want to distinguish within a policy whether we want
to return `deny' or `i do not care' (meaning i am not allowing it do
whatever others say'). 

In previous discussions it was noted that it seemed strange to allow
boolean expressions for combining policies and not allowing it for
rules. Personally i do not think so since boolean expressions for
combining policies have a clear semantics and work on the policy
outcome (not on the rules within them). 

If we go for policy combinations we may want to put some restrictions
on the target of policies appearing together in a boolean
expressions. Probably it should be enough to ask targets to be
overlapping (requesting equality would seem too strong). Evaluating if
targets are overalling may be not easy. Also if targets are only
overlapping it could be that one policy has nothing to say on an
access, probably on this case the policy should simply respond `i do
not care', (we could also use `not applicable').

An alternative way of defining policies on other policies is to
consider a policy as a set of policies and specify how they should be
evaluated in a metapolicy. The reason for such a solution would be to
be on line with how the rules are treated within a policy (in case we
define a policy as a set of rules). However, it does not seem to have
the same flexibility and expressiveness. Also, a metapolicy would need
in this case to refer to specific policy identifiers, while a
metapolicy is intended to describe behavior w.r.t. properties/types of
policies and rules.

METAPOLICY
----------
to do