Minutes F2F 13/14 March 2007

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.

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