> On Mon, 2008-09-22 at 10:06 -0400, Joly, Robert (CAR:9D30) wrote: > > <snip> > > > > > > It looks to me as though you unconditionally remove any PAI > > > header in > > > the message, and then later check to see if the > message is > > > authenticated and add one. If the header is already there and > > > signed, it seems to me we should just leave it > alone. > > > Am I missing something? > > > > > > In the patch, PAI header is removed only if it is not > > > signed/authenticated. > > > > > > > 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. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
