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

[Frank Siebenlist <franks@mcs.anl.gov>]

I've marked-up Hal's doc a little:

"http://www.mcs.anl.gov/~franks/xacml/access_control-xacml-3-fs.doc";

Regards, Frank.


Tim Moses wrote:

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

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory