OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Opened issue 32, Exception handling

    Posted 02-20-2007 12:13
    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.
    
    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
    
    
    


  • 2.  Re: [xacml] Opened issue 32, Exception handling

    Posted 02-27-2007 21:37
    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
    


  • 3.  Re: [xacml] Opened issue 32, Exception handling

    Posted 02-28-2007 07:10
    Anne Anderson - Sun Microsystems wrote:
    > 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
    
    Anne,
    
    Unfortunately, it isn't that simple. The PEP has to either let the
    access happen or stop it regardless of what happens on the PDP side.
    This means that the PDP has to provide sufficient information to the PEP
    so it can enforce something. In some cases the result from the PDP may
    be an indeterminate, in which case the bias of the PEP will make the
    decision.
    
    The real issue here is whether an error from an untrusted policy is
    allowed to influence the decision of the PDP. It isn't a simple problem,
    but Olav has an idea for how to do it. I haven't had time to write up a
    proper explanation of the issue yet though. I'll get back on it.
    
    Regards,
    Erik
    
    >>
    >> 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
    >>
    >>
    >