> >At Wed, 01 Jul 2009 12:16:12 +0800, >Song Haibin wrote: >> >I actually think this is a bad idea. Previous experiences >with trying >> >to design access control systems (see WebDAV ACLs) have >turned out to >> >be really overcomplicated. As far as I can tell, this isn't >necessary >> >for the SIP use cases. >> > >> >> As RELOAD is designed to support various usages. Other >usages may have >> this requirement. For example, we can image group communication >> scenarios, only members of a group can retrieve and modify the files >> belonging to this group. I think ACL might work. > >Sure. I'm not saying that one couldn't do an ACL extension to >RELOAD at some point in the future to support some future >usages. My point is that we don't need it for the current set >of applications. > > >> Could you tell me what causes the WebDAV ACLs overcomplicated? > >That people want to be able to specify complicated policies, >so once you open the door to ACLs it gets complicated. >And of course the situation here is inherently more >complicated since you're asking people you basically don't >trust to enforce access control for you. >
Thanks for explaining. I agree. I guess a shared group key may be a better choice, at least in p2p scenarios, it does not depend on a third party that you don't trust to enforce the access control. > >> >> Req. 12: It SHOULD be possible to limit the impact of badly >> >> behaving P2PSIP nodes on the overall system security. >There SHOULD >> >> be an option to identify malfunctioning or badly behaving nodes, >> >and exclude >> >> or reject them from the P2PSIP system. >> > >> >Hmm... It seems to me that this is already possible at >least in some >> >sense: you use short-lived certificates and then refuse to reissue >> >their certificates. Did you have something else in mind? CRLs? >> > >> I'm not sure about the solution here. I think it may be hard to >> determine the TTL for such kind shor-lived certificates. Misbehaving >> nodes still function in the overlay until its certificate >expires. Too >> short TTL may overload the CA anyway. I don't know how CRLs work in >> the overlay, in a p2p fashion or in a c/s fashion. > >Me neither. And since overlays are resistant to a certain >amount of misbehavior, I don't know if we need to solve this right now. > I prefer to mention the consideration to this problem in the security considerations of the base draft. Haibin >-Ekr > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
