Subject: Re: [P2PSIP] Dynamically introducing new types

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 5 Mar 2009 13:19:35 -0800

Apologies for picking up this thread after a really long period of silence.. a long vacation got in the way :) 

<snip> 

> >
> > What I meant was that the type of authorization rule applied will be
> > indicated in the message, rather than needing to look up a
> > configuration document.
> 
> I'm sorry, I still don't see how this is going to work: the
> sender and the receiver of the message are potentially adversarial:
> for instance, the sender may want to delete data belonging to
> someone else. This means that the recipient needs to be able
> to determine the correct access control rule in a way that
> the sender can't interfere with. Otherwise the sender can
> just choose an access control rule which is most permissive for
> his purposes.
> 

Sorry, I'm not sure I understand this. Are you saying that Bob could potentially choose an authorization rule that allows his ResourceID to map to Alice's ResourceID that followed the legitimate authorization rule?  That shouldn't happen with a good hash function.  And, in general, one node should never be able to delete data corresponding to any other node, unless explicitly authorized to do so.  A part of the problem here may be that RELOAD does not yet address delegation of data access control. I think that by default, data should be stored against the creator id, and data from one creator must never overwrite data from another creator.  We probably should also add support for ACLs of some kind to be associated with the data, thereby allowing the creator to specify other nodes/users that can actually modify their data.  

Apart from the above, I also want to go back to the set of authorization rules you had proposed: 

"   - User must have a certificate with H(user_name) == Resource-ID
     in order to write or delete.
   - User must have a certificate with H(user_name) == Resource-ID
     in order to write or delete and Node-Id matches the dictionary
     key [used for SIP Registration]
   - User must have a certificate with H(NodeID)    == Resource-ID
     in order to write or delete.
   - User must have a certificate with H(NodeID || integer) == Resource-ID
     for integer < X in order to write or delete. [used for TURN service]
   - Any user may write. User must have a certificate with H(user_name)
     == Resource-ID in order to overwrite or delete [allegedly useful
     for voice mail.]" 

I think we also need to allow for a rule where there is no constraint in the resource name construction.  Even though we don't yet have a kind that needs it (I'll argue in a separate thread that the TURN-SERVICE kind really should), this is very useful to have for allowing keyword-like searches eventually.  And, we can easily see that being necessary to support a generic suite of applications on the DHT.  In order to support this, I think we should allow for the case where any user may write or retrieve without constraints to the resource id - but, only the creator (or when delegation is possible, other nodes explicitly authorized by the creator) can overwrite or delete the data.  

Cheers,
Vidya