Subject: Re: [P2PSIP] Dynamically introducing new types

From: Eric Rescorla <[email-masked]>
Date: Fri, 09 Jan 2009 10:39:31 -0800

At Wed, 24 Dec 2008 13:05:26 -0800,
Narayanan, Vidya wrote:
> 
> What you are suggesting is to still do kind-specific data
> authorization and access control, but allow dynamic addition of new
> kinds.

Yes.

>  I think this works, but, it is simpler to just do this at
> the overlay level - this means indicating the type of authorization
> used in the protocol (say, we define the 5 or so rules you have
> below and allow that to be signaled in the protocol).

I don't understand what "signalled in the protocol" means.
This is being signalled in the protocol in the sense that
the protocol has a mechanism for moving the configuration document
around. 

  Having it
> tied to the kind allows additional verification that the particular
> authorization model is indeed the right one to use for that kind -
> unless we need that property, I don't see a reason to tie it to the
> kind itself. 

I'm sorry, I'm not gettign your point here: we already have
kinds which we expect to run on the same overlay which require
having different access control rules. So, yes, I think that
each kind needs to have its own set of rules in a working overlay.

> So, I prefer that we signal the authorization rule in the protocol
> rather than have this complexity of having kind level knowledge in
> order to perform the authorization.
> 
> All that said, I agree with the 5 rules you wrote below.  I'd
> recommend adding the following:
> 
> - User must have a certificate with H(NodeID || "usage specific string") == Resource-ID and 
> - User must have a certificate with H(user_id || "usage specific string") == Resource-ID
> 
> This allows the flexibility to usages to qualify the data they are storing as they see fit.  

I don't really understand how this works. Usages aren't a first class concept in RELOAD.
They're just a document organizational concept. The only relevant protocol concept
is "kind". If I do s/usage/kind/, is that what you are suggesting? If so,
where does the string come from.

-Ekr

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 9 Jan 2009 23:31:48 -0800

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Friday, January 09, 2009 10:40 AM
> To: Narayanan, Vidya
> Cc: Eric Rescorla; [email-masked]
> Subject: Re: [P2PSIP] Dynamically introducing new types
> 

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. 

> each kind needs to have its own set of rules in a working overlay.

I agree that the authorization rules itself are kind specific.  However, I'm saying that the node verifying authorization only needs to know which rule to apply - there is no need to verify that the rule applied is the correct one for the particular kind.  If we said that, there is no need to retrieve the configuration document and looking up the authorization rule corresponding to a kind.  The verifying node can apply the authorization rule indicated in the message and that will be sufficient. 

> where does the string come from.

I'm talking about providing application specific resource name construction flexibility.  A particular usage may decide to allow its data to be further spread in the overlay.  For instance, sip.voip:[email-masked] and sip.im:[email-masked] may be two different objects stored on the overlay by the SIP usage.  Here, "sip.voip" and "sip.im" are specified by the usage.  This would be carried in the message to ensure authorization verification by the target node.  The construction of the string itself is only of significance to the usage.  

Vidya

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 12 Jan 2009 07:47:49 -0500

Vidya,

I think you're right that a system could work that way, but it seems
too expensive to me.  Assuming that many/most overlays would only want
to store kinds that are authorized for the overlay, each kind requires
a description (which is rather small) and a signature (which is not).
The signatures in the messages already make them large enough that we
need to deal properly with fragmentation.  Adding an additional set
(or more) per message when we can just propagate the information once
in the overlay config file and be done with it seems like a waste.

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Jan 2009 12:55:56 -0800

At Fri, 9 Jan 2009 23:31:48 -0800,
Narayanan, Vidya wrote:
> 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.

> I'm talking about providing application specific resource name
> construction flexibility.  A particular usage may decide to allow
> its data to be further spread in the overlay.  For instance,
> sip.voip:[email-masked] and sip.im:[email-masked] may be
> two different objects stored on the overlay by the SIP usage.  Here,
> "sip.voip" and "sip.im" are specified by the usage.  This would be
> carried in the message to ensure authorization verification by the
> target node.  The construction of the string itself is only of
> significance to the usage.

Again, usages aren't a first class construct, so there's no 
way for a usage to specify anything like this. That's what
kinds are for.

-Ekr