> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Jan > Janak > Sent: Saturday, March 07, 2009 1:33 PM > > So a requirement to make the attack possible is that the user agent > responds > to challenges generated for in-dialog requests.
Right, and that the attacked domain accepts INVITEs from its AoR's with non-registered Contacts; or accepts INVITEs from its static AoR's to come in from unknown locations. That's pretty rare in my world, but ymmv. > > I do not see a > > big benefit in challeging in-dialog requests as these are hopefully > > rejected by the remote side if no matching dialog exists. > > Yes, hopefully :-). But what if not? What if you deploy a poorly > implemented > PSTN gateway which would happily process an in-dialog request with no > matching > dialog? Of course you can test the gateway before you deploy it if it is > under your control. At that point you're describing something that is fundamentally broken. All bets are off, including any preventative security measures you could take, etc. I mean at that point you could just say "what if the user/password is published on a web site?" > There are other cases where you know nothing about the target UA > implementation, such as when the users of your proxy call other users and > you > have no control over the UA implementation they use. Then get yourself a box that enforces the protocol rules in the middle. :) > > - I never unterstood why a proxy should pass through the authentication > > request from a foreign domain. > > Because this is how it is specified in section 22.3 of RFC3261. And it would have to continue to do so. There are actual use-cases for this. I think there's even a reasonable use-case for challenging in-dialog requests: connected-identity, for example. But you don't even need to challenge in-dialog requests for this form of attack: if the victim calls you, then you can challenge the initial INVITE. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
