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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
