OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Opened issue 32, Exception handling


Erik,

Erik Rissanen wrote On 02/20/07 07:12,:
> All,
> 
> I have opened issue 32, which has been closed, waiting for the
> delegation stuff to mature. I also added an problem to it which was
> discovered by Olav here at SICS. For your convenience, the text here:
> 
> 
>         32. Exception handling
> 
> Section 7.15.3 in the XACML 2.0 specification contains definitions for
> what diagnostic information the PDP shall return in certain cases
> (missing attributes). We need to see whether the delegation
> functionality affects any of this and how diagnostics of administrative
> requests are to handled when returning to the PEP. Also, the extra
> processing of delegation may introduce more diagnostic cases, for
> instance failed reduction.
> 
> There is also an issue with indeterminate results and delegation which
> has been explored by Olav Bandmann at SICS. In XACML 2.0, if a policy
> evaluates to indeterminate, in many cases the indeterminate result is
> pushed up to the final result, indicating that something went wrong.
> However, if a policy with an issuer evaluates to indeterminate, it is
> discarded (in the current draft 15). This means information about this
> failure is lost, and a valid result is returned, although there has been
> an error. In certain circumstances an attacker could exploit this. If he
> could for instance disturb attribute provisioning, he might be able to
> effectively disable policies, without there being an error in the final
> result.

The implementation could report an error on the PDP side, so the failure 
information is not necessarily lost.

Anne

> 
> On the other hand, we don't want to combine an indeterminate from an
> untrusted policy, since that would be an easy denial of service attack
> by someone who is able to publish policies.
> 
> One (the only?) way to handle this is to reduce indeterminate results.
> 
> 
> Regards,
> Erik
> 
> 

-- 
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]