> -----Original Message----- > From: Nils Ohlmeier [mailto:[email protected]] > Sent: Saturday, March 07, 2009 5:41 PM > > Am 07.03.2009 20:18 Uhr, schrieb Hadriel Kaplan: > >> 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. > > Luckily it seems we are not living in the same world :-) > I call it a feature that I can make authenticated calls without being > registered.
Why, is sending a REGISTER hard?? It looks like a simple enough message to generate. How about OPTIONS? (has anyone ever noticed that OPTIONS is an anagram for POTIONS, or "O, NOT SIP" or "ON TO SIP" or "TON-O-SIP" or "TIS NO-OP" or "I NO POTS"? weird) But anyway, sure - I'm not saying the attack isn't interesting or worth figuring out a solution/prevention for. I think it *is*. I was only challenging a claim that Service Providers on the Internet are currently exposed to it. Not all of them are. > >>> - 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. > > Could you please share one of these use-cases with me. Well, the 3GPP roaming case, for one. A pictorial version: http://www.tech-invite.com/Ti-ims-regflow-1.html > > 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. > > Sorry, but how is this going to work in world without a SBC which knows > my credentials? SBC's don't usually know your credentials, even now. They don't need to. But anyway, I'm not sure what you mean by the question. How is what going to work? Stopping INVITE-based authentication relay-attacks? You don't need an SBC-type box to stop that. Just disconnect the cable. :) Or, use the counter-measures in the draft. Or change the protocol, or at least the authentication mechanism. -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
