Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic keyword-like storage

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 Apr 2009 14:34:04 -0600

Vidya, I like this and think we should add it to the draft but one  
question. I worry about it being a  bit vague of it if is a  
certificate with same user id or node id that is allowed to do an  
update. I think we need to do one of two things

a) define this so the nodeid and userid are stored and a certificate  
that matches either the nodeid or userid is allowed ot update

b) define two new rules here, one that requires the node-id to match  
and ones that requires the userid to match. So we would have something  
like
NO-MATCH-CREATE-WITH-RESTRICTED-NODE-UDPATE
and
NO-MATCH-CREATE-WITH-RESTRICTED-USER-UDPATE

I'd probably prefer approach b to aproach a but don't feel strongly  
either way.

Thougths?

Cullen, in my individual contrubotro role

On Mar 22, 2009, at 8:31 PM, Narayanan, Vidya wrote:

> In addition to the access control rules defined in section 6.3 of  
> the draft, I think there is a need for a rule, where any node is  
> allowed to write to a Resource ID, but, only the creator is allowed  
> to modify or overwrite the entry by default.  This allows for  
> generic keyword-like storage on the overlay which will eventually be  
> needed to support various types of kinds and usages on the overlay  
> effectively.  The notion here is that no authorization is needed on  
> the Resource ID, but access control is applied to the data  
> operations, once it exists.  Here is suggestive text for supporting  
> this:
>
> "6.3.6.  NO-MATCH-CREATE-WITH-RESTRICTED-UDPATE
>
> This policy allows storage of data with no constraints on choosing a  
> Resource ID.  However, by default, only the creator of the entry is  
> allowed to modify or overwrite the stored data once created. The  
> user name and/or node id present in the certificate of the  
> requesting node MUST be used as the creator of the data.  Upon  
> receiving a request to store, a node MUST verify if it already has  
> an entry present for the particular kind and Resource ID  
> corresponding to the same user name or node id that is contained in  
> the Store Request.  If so, the received Store Request MUST be  
> treated as an update to the existing data and the appropriate checks  
> as described in section 6.4 must be applied.  If no corresponding  
> match is found, the StoredData contained in the Store Request  
> message MUST be stored as a new entry in accordance with section  
> 6.4.  This rule is useful for generic keyword-like storage on the  
> overlay, which is likely to be useful for several classes of  
> applications that may b
> e defined for use with RELOAD.  The access control allows ensuring  
> that the data created by a given node is not randomly overwritten by  
> any other node."
>
> It may be good to include the Resource Name in the StoredData  
> structure as well.  This will allow the storing node to more easily  
> create an index of the resources it is storing, which can then be  
> used for retrieval of data.  However, I think it will work even  
> without it - I'm looking for other thoughts on this.
>
> Thanks,
> Vidya
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 16 Apr 2009 10:45:59 -0700

Cullen,
I'm okay going with option b you mention below.  I think disambiguating node and user ids might be useful.  And, I don't think it is unreasonable to limit future updates to using the same id that was used at the time of creation.

Cheers,
Vidya 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Friday, April 10, 2009 1:34 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic
> keyword-like storage
> 
>