On Fri, 2008-10-24 at 14:46 -0400, Dale Worley wrote: > On Fri, 2008-10-24 at 12:03 -0400, Arjun Nair wrote: > > - Change this, so that all out-of-dialog REQUESTs are challenged, and > > in-dialog REQUESTs go through unchallenged > > - With an exception for REGISTER, as sipXregistrar is in a better > > position to authenticate them. So, no REGISTERs are challenged. > > - And an exception for OPTIONS, as they are great for debugging, so, > > we will not require any authentication from them either. > > > > - We use the presence of To-tags to test whether a request is in > > dialog or not > > > > Any comments on this? > > That sounds quite reasonable. > > > Also, we couldn't come to a definite conclusion for REFERs. Should we > > authenticate in-dialog REFERs? > > Authenticating in-dialog REFERs is part of how we make consultative > transfers work. What is needed for the cons trans mechanism?
No exception to the general in-dialog case is needed for REFER, though. The authproxy path will generate the challenges for them if needed. Just treat them like any other in-dialog request and don't challenge to add PAI. > > How about out-of dialog REFERs? > > I'm not convinced that anyone *uses* out-of-dialog REFERs, despite the > number of times I have seen mechanisms proposed in the IETF that use > them. But it's clear that if someone uses o.o.d. REFER for something, > the mechanism should require authentication (otherwise it would be quite > a security problem). So I vote for authenticating o.o.d. REFER. Agreed. I think we should have a short list of methods that allowed out-of-dialog (OPTIONS, at least) without challenge. All others should be challenged if they have on of our identities in the From header. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
