What you are suggesting is to still do kind-specific data authorization and access control, but allow dynamic addition of new kinds. 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). 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. Mainly, it avoids the complexity of having to deal with storing an updated overlay config document on the overlay and dealing with version control of it and so on. There is the problem of how does a node know that a given overlay config document is the most recent one. In general, I'm not a fan of introducing more functions that may need central control and coordination than nece ssary for a p2p system.
Especially in the case where any node is trusted to create new kinds, the kind-level complexity doesn't buy anything. In general too, I wonder about how much the property of verifying the right authorization model being applied to a kind is really buying. Every authorization rule we'd have should achieve the property of ensuring that only authorized nodes are able to write/modify a particular piece of data. Arguably, the data is not of much use unless the right authorization model was applied to it, as specified by the usage. The owner of the data gains nothing by applying the wrong authorization rule, as far as I can tell. And, if the wrong rule was applied, it likely cannot be queried that easily (given that usages will assume a certain authorization model to compute the resource id for a query). 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. - Vidya > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Eric Rescorla > Sent: Friday, December 19, 2008 8:44 AM > To: [email protected] > Subject: [P2PSIP] Dynamically introducing new types > > > One of the topics that came up a number of times in the RELOAD design > discussions, and then was recently raised by Vidya was the introduction > of new kinds. There are actually two issues here: > > 1. How to tell peers in a running overlay that they are now > required to support a new kind. > 2. How to introduce new kinds that peers aren't necessarily > assumed to know about. > > Problem (1) is a notification problem. Problem (2) is a problem of > adding enough richness to the configuration document that it can > describe new kinds to peers that don't already have software that > implements them. Note that problem (1) can exist even independent > of (2), if, for instance, you want to add a new kind defined in > some RFC, but that wasn't initially part of the overlay config. > It also applies if (for instance) you want to change the size > limits on a given kind. > > > INTRODUCING NEW KINDS > Let's deal with issue (2) first. > > S 11.2 currently specifies the following information in each > "required-kind" production in the configuration document. > > * name: a string representing the kind. > * max-count: the maximum number of values which members of the > overlay must support. > * max-size: the maximum size of individual values. > > I think when we defined "name" we were intending it to match up to some > name in an IANA registry, so you could look up the kind definition, > but it's unclear. > > In any case, I think what we want to do is the following: > > (a) Some kinds are defined in RFCs and they get defined names and > code points. > (b) Some large fraction of the code point space is reserved for > overlay-specific kinds that can be introduced by the overlay > configuration without IANA registration. > (c) The overlay configuration language is rich enough to allow the > definition of new kinds that are generally like the kinds we > already have. > > Note that I'm not suggesting that arbitrary non-configuration server > nodes be able to introduce new kinds. That seems to me to break the > security model (though see below for configuration update). > > In order to accomplish (c), then, we need to allow the configuration > document to specify the information in 6.3.5.3, namely: > > o The meaning of the data to be stored. > o The Kind-ID. > o The data model (single value, array, dictionary, etc.) > o Access control rules for indicating what credentials are allowed > to read and write that Kind-ID at a given location. > > The first element is just a freeform string. The second is an integer. > The third is just one of the data models. So, it's easy to specify > XML for all of these, but I won't try to do that here. > > This leaves us with the access control model. Rather than specify > a new language, I propose that we simply allow some finite (and small) > list of access control policies that map to what we know we are > currently using. Any more complicated access control policy requires > a new RFC (or something) to register the kind or the policy. Here's > the policies I think make sense: > > - 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.] > > This list is deliberately minimal, and I could be convinced to add or > delete one or two of these. My thought was we would just define these > by name (or number). Then you would introduce new kinds by saying, > for instance: > > <required-kind name="NEW-KIND" > kind-id="55555", data-model="single-value" > access-policy="username-match" max-values="10" > max-size="1000"/> > > > UPDATING RUNNING OVERLAYS > The other problem is how to update a running overlay to indicate that > a new kind needs to be supported. There are a number of possibilities > here. > > - Simply update the configuration management document and force > nodes to go back as needed (e.g., whenever they see an unknown > kind.) > - Update the configuration management document and have some > overlay-based notification protocol. > - Have some way to get the configuration document out of the overlay. > > The first two have the difficulty that they require a fairly high level > of uptime from the configuration server. In addition, the first > potentially > creates a lot of load on it from a misbehaving nodes which repeatedly > send bogus kind-ids. So, I lean towards the third option, but this > requires > two new technical capabilities: > > (1) The ability to fetch the configuration document from an arbitrary > node. > (2) A signature over the configuration document. > > (2) is easy and just requires protocol definitions. I can imagine a > number > of ways to do (1), but the most natural seems to be that we define a > new method/kind-id/something that lets a node say "give me the latest > copy of the config document you have" to any other node. This would > let you poll, and also when a node asks you to store new kind-id 5555, > it > presumptively knows about that kind-id and you can ask for a new config > document from it. > > As I said above, config documents need to be signed, presumably by the > certificate that the config server would use for TLS. However, if you > wanted to operate an overlay where anyone could introduce new kinds > (effectively where all are trusted), you could presumably operate > with unsigned config documents. > > -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
