Minor corrections made to text based upon input from Erik (denoted by
"|" on left margin). -bill
Minutes of XACML TC Face-to-Face Meeting
Austin, Texas; hosted by IBM Austin Research Lab
DAY 1 - 13 March 2007
I. Role and Administrivia
Attendees
Hal Lockhart
David Lin
Anthony Nadalin
Ron Williams
Argyn Kuketayev
Abbie Barbir
Prateek Mishra
Erik Rissanen
Bill Parducci
David Staggs
Rich Levinson
Proposed agenda reviewed and adjusted
II. Discussion
Refer to XACML 3.0 Issues list at
http://wiki.oasis-open.org/xacml/IssuesList
- ISSUE#32: Exception handling
Thread at:
http://lists.oasis-open.org/archives/xacml/200702/msg00034.html
SUMMARY:
Administrative Policy reduction Cases:
1. Not Applicable => no reduction
2. Permit|Deny => reduce
3. Indeterminate => reduce
If reduction performed, Indeterminate results are carried up (as
Indeterminate)
General consensus is that all Indeterminate results need to be
reduced.
VOTE: APPROVED AS PROPOSED.
DISCUSSION:
Currently: if don't get a trusted path leading to Permit or
Deny, then the policy is dropped.
Proposed solution: 1) reduce as now, following Permit/Deny
results: if normal path reduces, OK - take that; otherwise,
2) Follow paths for Indeterminate (both for admin policies
and access policies). See if "potentially" Permit or Deny.
If reach a trusted policy that way, then Access Policy is
Indeterminate. (could get more complex, and if all Rules in
the Policy are Permit, then would not need to try reduce as
potential Deny).
Potential for Denial of Service (DoS), everything is done
twice at each level. Good news is that if you start from
Trusted Policies and evaluate toward the Access Policy, you
don't run into this problem.
Hal: need to optimize for most common case - one-level
delegation, etc.
Erik: but have to analyze complexity of worst case. Want to
make sure someone can't submit an untrusted policy that
causes indefinite evaluation.
Tony: what about backwards compatibility?
Bill: this is actually closer to what we do now - we bubble
up Indeterminate now if don't get a definite Permit or Deny,
and proposal is that Indeterminate would bubble up in the
Admin Policy case also.
NOTE: Diagrams, etc. in Erik's e-mail description of the
problem are with respect to "new" deny-overrides algs:
propagate Indeterminate rather than "potential deny" and let
PEP decide.
NOTE: paths in graphs of "proposed solution" description are
not PolicySets, but reduction paths. Arrows mean that the
policies were authorized by policy at the end of the arrow.
NOTE: Olav's model includes three "flavors" of Indeterminate:
{potential Permit, or Deny, or N/A}, {potential Permit, or
N/A}, {potential Deny, or N/A}.
- NEW ISSUE#72: Need better specification of where PEP-supplied
policies go
Now a supplied PolicySet would end up being parallel to
existing inner PolicySets, which violates current model. See
related Issue#73.
- NEW ISSUE#73: Can AdminPolicies be in different PolicySet
from Access Policy.
Related to problem of scope of evaluation: want to be able to
do reductions "locally". What are the rules for where
policies are placed in the Admin Policy model? "At which
level in the Admin Policy model does reduction start?"
- ISSUE#50: Maximum Delegation Depth
Brief overview of the issue:
Currently we do have a Boolean on whether delegation allowed at
all. Issue has to do with more complex specification of actual
allowed depth.
Currently, delegation depth in Admin Req can now be specified in
an arbitrarily complex way because it is constrained by the
Condition in the XACML policy. Currently delegation depth is an
Attribute in the Request; Admin Policy may have a Condition
saying {"Deleg depth" = 5} OR {"Deleg depth" = 7}, or something.
If just change delegation depth condition to be an upper bound,
then it is hard for an implementation to tell if it is part of
the Condition.
Bill: Seems like delegation depth might need to be a PEP
control, and not an Administrative control. An administrator
might add a delegation depth, and all of a sudden lots of
policies start being invalid.
Erik: a deleg depth will only affect that admin's own policies.
Erik: If allow variable delegation depth, reduction becomes NP
complete. If reducing from the bottom up, have to backtrack and
attempt another path if delegation depth exceeded. If do
| reduction top down, can't do deleg depth. This is a suspicion
| Erik has not performed a proof
Hal: why not just do reduction as now, but keep track of depth
and stop if exceeded.
Erik: Depth not known until reduction done.
PROPOSAL: Add new "custom" element to express "maximum depth" as
an integer.
ACTION: Erik to write-up formal proposal based upon integers.
- NEW ISSUE#71: Treat different Subjects with same
SubjectCategory as different entities.
Currently, XACML 2.0 does not treat different
SubjectCategories as different entities; all Attributes are
lumped together as if they were one entity.
Anne: presented limit-scope:all and limit-scope:atLeastOne from
WS-XACML specification.
Erik: this would require the arguments to the limit-scope
functions to be treated as strings that are passed to the
function itself, which would evaluate them using XACML
semantics. e.g. Enclose all the arguments in an