RE: [xacml] 7.7 Obligations

[Polar Humenn <polar@syr.edu>]

On Wed, 9 Oct 2002, Anne Anderson - Sun Microsystems wrote:

> I agree with Michiharu.  To restate:
> 1) Return a set of obligations with the understanding that
>    the PEP is expected to DENY access if it does not understand any one of
>    the obligations.  This is better than the PEP trying to tell the PDP
>    ahead of time which obligations it does understand.  The "deny if not
>    understood" method has been working fine for PKIX critical extensions.

This works for PKIX criticial extensions in the fact that if you don't
understand the extension and it is marked critical, the certificate does
NOT VALIDATE. That is sutble different ball of wax altogether.

In PKIX the default position is that the certificate considered INVALID,
unless PROVEN valid, by the algorithms set forth in the PKIX X.509
profile.

If we take that stance, then we might be better to say that the standard
default for a PEP to interpret a PDP answer is to deny access UNLESS the
PDP issues a VALID "Permit" response. A VALID "Permit" response is one
that, besides satisfying all the trust rules of signatures and talking
with a PDP, is one in which all obligations, if any, are understood by the
PEP.

You will notice that this covers the cases for Indeterminate and
Inapplicable as well, such that the PEP should deny access in this case.

First of all, let me say that I am not against this interpretation, it
just must be stated clearly and concisely, and not with a lot of drawing
Venn diagrams around MAYs and SHALLs to figure out the interpretation.

NOW: The BIG PROBLEM IS a PEP configured with MULTIPLE PDPS!

We can get around that by stating what the interpretation is for a SINGLE
PEP to PDP relationship, which I believe will be the single most widely
used configuration.

Anything after that, is up for latter discussion, or perhaps with another
specification about PEP configuration interfaces.

> 2) Obligations associated with an authorization decision of DENY are
>    perfectly reasonable.  For example, "DENY" access and log the fact that
>    this user tried to gain access.

I don't mind obligations on Deny. However, I don't believe in the "ERROR"
case, if obligations are non-understood by the PDP. I don't know what
ERROR means for a PEP. Furthermore, there is no way to fix it. A PEP can't
issue anything different to get an answer. However, a PEP can deny access,
and try to fullfill all obligations it can, perhaps in an application
specific way, notifying somebody that it is getting non-understandable
obligations. That should probably happen in the Permit case as well, but I
don't think we need to go that far for either. A good implementation may
do that.


-Polar


> "Michiharu Kudoh" <KUDO@jp.ibm.com> wrote:
> >Date: Wed, 09 Oct 2002 20:24:14 +0900
> >Based on the discussion on the list,
> >- Bill and I are in agreement.
> >- Daniel seems to be uncomfortable with an authorization decision like DENY
> >with obligation(s).
> >- Polar seems suggesting to include understandable obligations in the
> >request context to avoid emitting no-understandable obligations to PEP from
> >PDP.
> >
> >My opinion is that DENY with obligation (e.g. deny provided access must be
> >logged) is still useful for some applications e.g. security policy for a
> >firewall server and an authentication server. For example, "DENY with
> >notify-admin" means that the access is rejected but the notification of the
> >access must be sent to admin. The TC approved to include this long time
> >ago.
> >
> >For the no-understandable obligations, the Polar's suggestion to include
> >understandable obligations in request context might be one option. It
> >definitely eliminates the case when the PEP receives non-understandable
> >obligation from the PDP. But I have a slight concern. What if there are
> >hundreds of obligations the PEP understands? Then I don't think it is an
> >efficient way to mandate to include all the understandable obligations in
> >each access request because it may make access request very large, even if
> >such information is irrelevant to many access requests. Another way would
> >be to create a communication protocol between PDP and PEP to exchange a
> >list of understandable obligations, but it seems outside the scope of
> >XACML. XACML should focus on what decision must be generated in response to
> >what decision request. Therefore,  I would prefer my original definition
> >that includes the case when the PEP does not understand the obligation.
> >
> >Michiharu Kudo
> >
> >IBM Tokyo Research Laboratory, Internet Technology
> >Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
> >
> >
> >
> >
> >
> >----------------------------------------------------------------
> >To subscribe or unsubscribe from this elist use the subscription
> >manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> Anne
> ---------
> Anne Anderson                     Anne.Anderson@Sun.COM
> Internet Security Research Group
> Sun Labs, Burlington, MA          Phone: 781-442-0928
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>