RE: [xacml] Review of 10. Security and Privacy section

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: RE: [xacml] Review of 10. Security and Privacy section

I completely agree on points 1-3.

> On 21 August, Carlisle Adams writes: [xacml] Review of 10.
> Security and Privacy section
>  > 1. Should this be called "Security and Privacy
> Considerations" instead of
>  > just "Security and Privacy"?
>
> Yes.
>
>  > 2. In the "Statement Level Confidentiality" section, 1st
> paragraph, it says
>  > "... a PRP only needs access to the target elements in
> order to find the
>  > appropriate rules".  Should this say "rules/policies", or
> just "policies",
>  > instead of "rules"?
>
> Just "policies".  A PRP no longer has to "find" rules.  The PDP
> will "find" rules within a policy based on target matching.
>
>  > 3. In the "Policy Integrity" section, 4th paragraph, it
> says "The PDP SHOULD
>  > NOT request a rule based on who signed the rule...".  Should both
>  > occurrences of "rule" be "policy"?
>
> Yes.
>

First of all, this is intended as a cautionary example. However, this is a real world problem that affects my product, and all of our compeitors. I can show you security holes posted to BUGTRAQ, for example, where this occurred. We have struggled with it for years. The Not Applicable == Permit behavior is not only standard for web servers, it is embedded in the Java Servlet and JSP specifications.

The logic is that only a small portion of the resources on a public web server are protected, so people want to only specify rules for those that are. If the namespace is not conveniencely laid out (as most are not) it may require a number of rules just to specify all the pages that are not protected.

I don't think we can ignore the problem or pretend it doesn not exist. That remidns me of the REST people who keep saying GET only does read.

Hal

>  > 4. In the "Resource Matching" section, 1st paragraph, it
> says "... the
>  > policy result of "Not Applicable" is treated as equivalent
> to "Permit" as is
>  > common in many web servers".  I'm a bit surprised that this is true
>  > (although I probably shouldn't be!).  In any case, we
> probably don't want to
>  > encourage this behaviour.  Should we simply not mention
> this, or should we
>  > at least say that this behaviour is not recommended?
>
> Let's not mention this or else say not recommended.
>
> Anne
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>