Re: [xacml] xacml, policy, issuer, combinator parameters...

[Polar Humenn <polar@syr.edu>]

I'm going out of town in a minute and will not be back until monday.

I was going on about your trust chain validation stuff, because you
brought it up.

The problem with putting an element such as <Issuer> in a policy statement
is that now you've introduced one extra level of trust. Instead of having
just a policy A, which may be validated and issued, now you have Frank
says A. And since that policy has to come from somewhere, and be
validated, now you have, Somebody says Frank says A. Which in a sense,
makes the statement *weaker*. However, we haven't even really agreed that
is what it means.

Furthermore, I think for 2.0. The push seems to add this schema element
into the policy *in a hurry*, so we can do something with it *LATER*.

I think that is reckless way to go. We have no consensus on how this
element is to be used.  Combining Parameters can be used to state the
"issuer" of a policy, when somebody defines the combining algorithm that
uses this "issuer".

And there is no change to the schema. Other combining algorithms do not
have to be changed to state what to do with a new element and every other
problem in consistency it may cause.

I'm outta here. Have a good week.

-Polar


On Mon, 19 Jul 2004, Frank Siebenlist wrote:

> If you have an edge server that does the authentication and an
> application server behind it where access control decisions are made,
> then the app server *says* (ssl-session key *says* (edge-server key
> *says* (edge-server-DN *says* access-subject is polar))). In other
> words, we have learned to deal with all these different entities in the
> validation trust chain such that we can insert "polar" as the
> access-subject in the request context.
>
> If we use an external attribute validation service, which we send all
> the saml assertion that will get validated on their signatures and such,
> and which will give back a simple statement that "polar stated that
> frank is part of the friends group": validation svc *says* (polar *says*
> frank is friend).
>
> If we validate an x509 certificate with a subject name polar, then we
> may have to jump through hoops, cross certification, processing
> incomprehensible extensions, and end up with the app service x509
> validation code *says* (x509 church/religion *says* access-subject name
> is polar).
>
> In other words, we deal with these construct all the time right now,
> without having to consider any policy issuers. In the end, however, we
> manage to process and validate the different assertions such that we can
> "simply" add them in the end as binding that were issued by "some"
> entity. Along the way we have to make authorization decisions about the
> made statements, and one could even argue that for some one could use
> xacml/pdp again... but that is all with the purpose of filling in the
> request context for the original question whether an access subject can
> invoke an action on a resource.
>
> Again, I do not see why this is any different with policy assertions,
> and why this has anything to do with the question where we keep the
> issuer-policy association.
>
> This was really my last email about this ;-)
>
> -Frank.
>
>
>
>
> Polar Humenn wrote:
>
> >On Mon, 19 Jul 2004, Frank Siebenlist wrote:
> >
> >
> >
> >>I simply don't understand why you even want to have a discussion of how
> >>a policy "written" by polar becomes "mine".
> >>
> >>
> >
> >because it happens all the time.
> >
> >And given the element, it just makes that sort of thing possible, possibly
> >leading to ambigous behavior.
> >
> >
> >
> >>The reduction: polar *says*
> >>A & frank *believes* polar => frank *says* A...  is at the heart of the
> >>proposed scheme....
> >>
> >>
> >
> >True, the logic of Abadi, Burrows, Lampson, and Wobber, the following is
> >valid in all applicable models:
> >
> >Polar says A
> >Frank believes (speaks for) Polar
> >
> >then
> >
> >Frank says A
> >
> >However, we must be really careful about this.
> >
> >First and foremost, if you have a policy that states "Polar says A", then
> >who said that statement? This policy may be a lie. Furthermore, you may
> >not even know who Polar is.
> >
> >So, the fact that Frank *believes* Polar
> >
> >has no real effect if indeed, Carol says (Polar says A).
> >
> >So, the question is not that Frank *believes* Polar. It may be one of,
> >does Frank *believe* that somebody else says Polar says A.
> >
> >it gets complicated, but we can work through it.
> >
> >My point, is that if you put that <Issuer> in the policy, the policy no
> >longer just states who has access, but now states somebody else says who
> >has access, and there is a complicated question if that should be
> >believed, and where it should be believed.
> >
> >Putting the "issuer" as a combining parameter associated with a
> >particular policy states to the combingin algorithm that "this issuer"
> >states that "this policy" says who has access. and in the context of "this
> >combining algorithm" we have a mechanism for discovering and validating
> >the authority chain.
> >
> >If <Issuer> is to exist within a policy, what does it mean?
> >What does it mean in the context of a combining algorithm
> >Furthermore, the real question that must be answered, must be
> >What does an <Issuer> element mean for *all* combining algorithms?
> >
> >Cheers,
> >-Polar
> >
> >
> >
> >
> >
> >
>
> --
> Frank Siebenlist               franks@mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
>