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 On Sat, Jan 10, 2009 at 2:31 AM, Narayanan, Vidya <[email protected]> wrote: > > >> -----Original Message----- >> From: Eric Rescorla [mailto:[email protected]] >> Sent: Friday, January 09, 2009 10:40 AM >> To: Narayanan, Vidya >> Cc: Eric Rescorla; [email protected] >> Subject: Re: [P2PSIP] Dynamically introducing new types >> >> 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. >> > > 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. > >> >> 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. >> > > 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. > >> >> > 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. >> > > 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 protected] and > sip.im:[email protected] 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 > >> -Ekr >> > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
