> On Mon, 2008-09-22 at 10:50 -0400, Joly, Robert (CAR:9D30) wrote: > > > > > I think that this opens a security hole. Let's say that I > > > receive a > > > > call from userA. That message will carry its PAI > > > information. If I > > > > turn around and forge a new message that carries its PAI and > > > > proper ingredients to make the signature pass then I can make a > > > > call using userA's permissions. I think it would be safer to > > > > remove all pre-signed PAIs on incoming dialog-forming > requests and > > > challenge the caller. > > > > > > But a spiraled request looks just like a "pre-signed" > > > request... you don't want to challenge on every spiral, > and we have > > > no secured means of detecting the difference. > > > > > > > The current implementation of the PAI feature already leverages the > > presence of RouteState and the x-sipx-spiral header to only execute > > the PAI logic on incoming dialog-forming requests and not > on spiraled > > requests. > > x-sipx-spiral doesn't help, since it's not authenticated in any way.
Argh! That is correct. How about stripping the signature from the PAI as the request leaves sipXecs then? The NAT Traversal feature already introduced a new flag in AuthPlugin::authorizeAndModify() to tell plug-ins when requests are done spiraling so building or modifying a plug-in to strip the signature would be trivial. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
