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

[Tim Moses <tim.moses@entrust.com>]

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

Colleagues - On deletion, I agree with Erik.  The PRP, whether it is part of the PAP, part of the PDP or a separate entity, can enforce the rule that only the issuer of a policy can delete it, simply by removing it from the repository.  This should give sufficient control.  All the best.  Tim.

-----Original Message-----
From: Erik Rissanen [mailto:mirty@sics.se]
Sent: Thursday, March 24, 2005 8:21 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Groups - XACML v3.0 administration policy, working draft 01, 22 Mar 2005 (access_control-xacml-3.0-admininstration-spec-wd-01.doc) uploaded

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

---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org