Re: [xacml] Groups - XACML v3.0 administration policy, working draft01, 22 Mar 2005 (access_control-xacml-3.0-admininstration-spec-wd-01.doc)uploaded

[Erik Rissanen <mirty@sics.se>]

Hello all,

I think this new proposal is very good. It is close to what I did, but
cleaner since it does not use obligations. However, I have a couple of
questions/suggestions.

I will start with the last page in the proposal. I did not write
anything about deleting policies in my own proposal, but I and Babak
have given it a lot of thought. We agree on that editing existing
policies would be too complex to be workable. We therefore think that
the right solution is to have only two administrative actions, create
and delete, as is suggested in Hal's/Tim's proposal. The right to create
is defined by administrative rights. What remains is to define who has
the right to delete a policy.

Firstly, we can note that the owner of a PDP or the policy repository
has full control over the policies that go into the PDP, so he can de
facto delete anything. This kind of falls outside the scope of the
policy model, but might be worth mentioning, and can be useful in
certain situations.

A simple model for the right to delete is to say that the only one
authorized to delete a policy is the issuer of that policy. This is what
we do in our application and we implement it by means of a signed
revocation. It is a model that is simple and there should be no problems
with wrongful deletion of negative rights, since the issuer of the
negative right would be the only one allowed to remove it. (Though we do
not have any negative rights in our application anyway.)

It is possible to define other kinds of models for authorizing a delete.
Babak wrote a paper in which he describes a model in which the issuer of
a supporting policy may delete (revoke) the supported policy. See

http://www.sics.se/isl/pbr/papers/fast03.pdf

However, this may not be useful in practice since the revocation is done
on policy instances, not policy contents. The issuer of the revoked
policy could just reissue the same contents in a new instance. So if an
issuer of a supporting policy wants to delete a supported policy, what
he really needs to do is to replace the supporting policy with one that
does not support the policy he wants to go away. Thus, he would revoke
his own policy and reissue something different.

I have given it a lot of thought, and I think all use cases can be
covered with the simple model which says that the only one authorized to
delete a policy is the issuer of the policy to be deleted. I am
interested in knowing of any use cases that are not covered by this model.

The potential difficulties with this are whether administrators will be
able to understand the support relations between the policies, so they
will know what changes are needed to get the results they desire, but
this is not specific to this case, but rather it is probably the main
general issue with administrative delegation of the kind in the current
proposals.

Some other comments: At line 93 of the document it is stated that
specifying constraints on delegation is too complex to be workable. What
is meant with this? That it is too hard for people to understand? That
it is too inefficient? Or is it simply impossible to do it? The code I
wrote implements this, and if I understand the processing model
description in section 5, it would not result in any additional
complexity to include it. The description of the processing model is
slightly unclear to me, so I might be mistaken.

If I understand it correctly, each pool is associated with an "issuer".
It is set to the issuer of the access policy at the start of the
processing, and at each iteration of the main loop, replaced to be the
issuer of the administrative policies. Am I right? The text does not 
say so, but I would assume it, and that is how Frank's proposal works if
I understood him correctly.

If this is how it works, it is possible to maintain a list with all the
previous issuers of the pool in the order they appeared and check that
list against a delegation chain constraint. The simpler model which only
checks the depth of delegation, would check the length of the issuer
chain with a number in the administrative policy.

The checking of the delegation constraint would of course cause an
overhead to do the calculation to compare the chain with the constraint,
but the overall complexity should be the same, since each distinctive
issuer chain would result in its own pool anyway. What I mean is that
the number of pools simply reflects the branching in the backward
chaining tree. Delegation chain constraints would not change the
branching factor. Please correct me if I am mistaken.

One more thing that is unclear to me: What is done with the pools issued
by root that are "set aside"? The text does not explain that.

At step nine in the processing model, the deny results of administrative
policies are discarded. Wouldn't it be possible to generalize the
processing model to include negative administrative rights? I don't have
any use cases for them, but for the general standard it might be useful.
Though it is not clear to me who should define the combining algorithm
for intra-issuer administrative policy conflicts.

I have also thought a lot about optimization of chaining. A couple of
years ago we had an implementation of our adminsitration model which
flattened the chains. It was possible since we used a policy model which
was restricted in a way which made all rights comparable. We could say
whether one "situation" was a restriction of another situation without
having access to the subject attributes. However, this model was not
enough for our use cases. The problem is if the rights are comparable in
this way, it is not possible to combine rights from the different
sources. For instance A delegates right X to C and B delegates right Y
to C. It would by useful for C to be able to combine the rights X and Y
into one right Z, for instance if there is a role in C's organization
that needs both X and Y.

The new proposal discusses the possibility of splitting policies, which
might solve this problem, but I would guess it is too complex to be
workable in general. I'll think more about this.

My final comment (this is getting really long now :-)) is about
flattening chains and the problem with attributes. The real problem is
not having the attributes available. That should be solvable in some
way. The real problem is that the attributes might change, thus
invalidating a previous flattening of a chain. Depending on how we
define the semantics of the support relation relative to attribute
dynamics, the chains become more or less dynamic.

In the implementation I made over Christmas, I defined the semantics to
be such that all the attribute conditions are validated in respect to
the attributes that are valid at the time of the access request. In
principle this requires a revalidation of all chains at the time of the
access request, but of course there might be tricks to be used to
optimize it so equivalent semantics are achieved without actually
performing all of the validation. I haven't done any work on this, so I
do not know how feasible it would be.

Another option is that the access subject attributes are validated with
regard to the attributes that are valid at the access request time, but
the issuer attributes are validated with regard to the attributes that
were valid at the time a policy was issued. This means that attribute
dynamics becomes less of an issue, since if you verify that a given
issuer satisfied the attribute constraints at the time of issuing, that
validation result will not change in the future. (Actually, we might
want to revoke retroactively the attributes of a user in case of a key
compromise for instance, but I will ignore that issue for now.) This
would significantly simplify any flattening of chains. The earlier
implementation we did in fact worked like this. The attribute semantics
together with the comparable "situation" made it possible to completely
flatten all chains for the indefinite future.

One problem with these semantics is that in a distributed system, we
cannot trust the timestamp of the signature of a policy, since it is
generated by the issuer himself. If he wishes, he could generate a
timestamp back in time to "get access to" attributes that he no longer
possesses. This could be solved in some cases with trusted time servers
which act as witnesses to the signning/issuing of policies, but would be
an unwelcome complication.

Anyway, I think this is enough of comments for this time. I will be at
the meeting tonight. (I missed the meeting last week because I was at a
meeting in London.)

Best regards, Erik




tim.moses@entrust.com wrote:

>This is simply a recasting of Hal's proposal in the OASIS format plus aproposal for schema changes that conform with Hal's proposal.
> -- Tim Moses
>The document named XACML v3.0 administration policy, working draft 01, 22Mar 2005 (access_control-xacml-3.0-admininstration-spec-wd-01.doc) has beensubmitted by Tim Moses to the OASIS eXtensible Access Control MarkupLanguage (XACML) TC document repository.
>Document Description:Initial working draft
>View Document Details:http://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=11970
>Download Document:  http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/11970/access_control-xacml-3.0-admininstration-spec-wd-01.doc
>
>PLEASE NOTE:  If the above links do not work for you, your email applicationmay be breaking the link into two pieces.  You may be able to copy and pastethe entire link address into the address field of your web browser.
>-OASIS Open Administration
>  
>