Re: [Sip] draft-state-sip-relay-attack-00

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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