[xacml] Minutes of Policy Subcommittee concall (Wednesday Mach 6, 2002)

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

MINUTES OF THE POLICY MODEL SUBCOMMITTEE (WED. March 6 2002)
===============================================================

PRESENT

* Carlisle Adams (Entrust)
* Anne Anderson (Sun) 
* Simon Godik (self)
* Pierangela Samarati (Unimi)
* Tim Moses (Entrust)
* Michiharu Kudoh (IBM)
* Polar Humenn
* Ernesto Damiani (unimi)
* Sekhar Vajjhala (Sun) 

---------------------------------------------------------------

The agenda for the concall was to clarify the ideas and possibly reach
some consensum on

- Format of rules
- Format of policies
- Metapolicies

The discussion started on the topic of `target', which is the
information associated with the policy. It is noted that the target
has a twofold functionality. One of the reason for using a target is
EFFICIENCY, if a target is associated with a policy, all policies not
relavant for an access request (i.e., for which the request does not
match the target) can be simply ignored, returning `policy not
applicable'. The second reason for the use of a target is defining
APPLICABILITY, there are application scenarios where specific policies
are though of and should be applied only for certain requests
(cf. Ann's example of Sun's policies for subjects over 55).

The two aspects bring two apparently conflicting requirements on the
format of target. For efficiency the target  should be simple, it
should be a value (or set of them) on which you can index. For
applicability, the target should be expressive (simple triples
identifying the ground values for subject,resource, and action to
which the policy applies would not be enough). 

A possible solution encountering both requirements could be to
consider target of the format: (triple, conditions). The triple is a
triple (subject,resource,action) and provides the elements on which to
index, the conditions is a boolean expression over SAML attributes and
provides expressiveness.

Next the discussion proceeds on the format of rules and policies.  The
discussion makes it clear that the two terms are being referred with
different semantics by different people. Our draft document (Tim's
version 9) is being updated to provide a consistent terminology that
would help in avoiding ambiguous use of the terms.

Most of the discussion focusses on the format of rules and
policies. The current proposal seems to allow rules (used here in the
intuitive way of authorizations) to be combined in a boolean
expression to form a policy.  Pierangela points out that boolean
expression of rules do not seem to have a clear semantics. The
contrary is for boolean expression of policies which can instead be
used (with a clear semantics that we can define) to specify complex
policies. Anne notes that in some cases i may want to combine (with a
boolean expression) only the conditional portion of the rules
(intuitively the one describing to which accesses and at which
conditions the rule effect applies). It is noted that such a
combination should not be expressed as a combination of rules, it
seems more to be a use of macros (i can refer with a name to an
expression of conditions that i have predefined and i can reuse).

Another issue discussed concerns the effect of the policy. The current
proposal considers three options: 'permit if', 'permit only if',
'deny'.
Excerpt from status msg circulated earlier
---------------
  ``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 explicit support of denials since it predefines the
  way rules should be evaluated (intuitively, it corresponds to the
  support of denials-take-precedence).  
  ref: http://seclab.dti.unimi.it/~samarati/Papers/sec01.ps

--------------

By contrast explicit denials could be used to specify negative rule,
leaving then to an associated metapolicy the specification of how
denials and permissions should be combined.

Pierangela notes that the support of all three kinds of rules seems
redundant (probably support for deny subsumes the 'permit only if').

There is a discussion about the rule and policy concepts being
combined as a single concept in the current approach. Pierangela,
Simon, Sekhar, and Ernesto believe that the model should instead
clearly distinguishing between what is a rule (i.e., authorization),
and a policy (set of authorizations or combination of other policies).
Tim reports that there is a higher notion of policy manifest in the
current proposal whose name should be changed to policy, and that this
could address (either totally or in part) this problem.

In the discussion, metapolicies have also been mentioned, with
reference to them it is noted that metapolicies (as Carlisle pointed
out in the past) should refer to properties of the policies or rules
to which they apply, not to specific identifiers.

Tim reports that he is modifying the draft, also addressing some of
the issues that have come up in previous emails and the present and
past discussion, and version 10 will be provided by Friday.