Hi Vidya, So one of the key questions here is what are the use cases for updating configuration documents.
- a managed overlay, where what the overlay supports is determined by the entity managing the overlay. In this case, the manager is the only entity that should be able to authorize new kinds on the overlay. Such a manager would also have contact with the overlay and the ability to inject a new configuration document. Such a document will propagate very fast once it is introduced on only a single peer. There's no requirement that the actual "enrollment server" be on the overlay, only that a document signed with the appropriate key can be introduced onto a peer. Given a CE overlay, for example, one could imagine new versions of the product (or products) being issued new configuration documents as new kinds are required. The result is that the CE devices automatically update to the newest config document whenever a new device appears on the overlay, and thus before any new kind is used on the overlay. - The choice of self-signed peer certificates is orthogonal to the question of the key used to sign the configuration document. However, if you choose to deploy an overlay where anyone can generate a new config document, I think you're right that there could be a problem. I could imagine a solution where any peer that notices its resource is not in the current configuration updates the config file, but I'm not convinced there is a significant need for this type of scenario. I'd be interested in use cases you believe would be deployed this way. I don't believe that the security issues of not having a list of auhorized kinds, even simply registering garbage in the overlay, can be ignored for many or even most overlays. Bruce 2009/3/23 Narayanan, Vidya <[email protected]>: > The current RELOAD draft assumes that the configuration document specifies > the kinds, the associated data models and authorization rules that are > applicable for the overlay. While it may be okay to specify the kinds the > overlay supports (thereby giving a notion of available services and > applications on the overlay), the other two things make this configuration > document relevant during the operation of an overlay itself (rather than > configuration just being a one-time thing prior to joining the overlay). > This is undesirable in my view. For one, this involves the enrollment > server into the overlay functional aspects, which departs from the notion of > enrollment being a one-time thing (and the enrollment server itself not > being a part of the overlay). It also brings the question of how the latest > configuration document is made available on the overlay – the enrollment > server is not necessarily a peer or a client that can publish information on > the overlay. > > > > On the other hand, I think that this role for the configuration document in > normal overlay operations can be eliminated if the requirement for knowledge > of kind to authorization rule mapping is lifted for performing the > authorization itself. The storing node technically only needs to know the > particular authorization rule that has been used for the data to be stored > and verify that it passes authorization. The enforcement of whether that is > the right authorization for that kind can be done by the actual kind itself > (or the usage that uses that kind). The downside of this is that a > particular misbehaving node may use a different authorization rule than what > is expected for a given kind. This may at best result in garbage being > stored along with other data at a particular resource id. For instance, if > Alice is well behaved, h([email protected]) may contain an IP address to > reach that AOR. Eve, a misbehaving user, may store some other junk at > h([email protected]) using a more flexible authorization rule (at the > moment, assuming a good hash function, I can only see this being feasible > using the rule that places no constraints on resource id generation). By > ensuring that data from one creator doesn’t overwrite data from another > node, except explicitly authorized by the creator, h([email protected]) will > now have data corresponding to multiple creators. When the data is > retrieved for consumption by a usage, it can apply an additional check to > ensure that only the data with the correct authorization model is actually > consumed. It is also possible to place that restriction at the time of > retrieval to prevent all junk from being transported (to save bandwidth, for > e.g.). > > > > There doesn’t appear to be much downside in doing the above. However, I’m > open to other solutions that can take the configuration document out of the > overlay operation semantics. I’d like to keep the enrollment server (or > any other centralized entity) to the role it is actually meant for – the > more we engage these entities in overlay operations or kinds or usages, we > start placing more restrictions and make it difficult to use the same design > with self-signed certs and so on. > > > > Vidya > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
