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

Hadriel Kaplan <HKaplan@acmepacket.com> Sat, 07 March 2009 20:45 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C899528C1A1 for <sip@core3.amsl.com>; Sat, 7 Mar 2009 12:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level:
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJGVvrRIFuCe for <sip@core3.amsl.com>; Sat, 7 Mar 2009 12:45:31 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CF6E828C1A4 for <sip@ietf.org>; Sat, 7 Mar 2009 12:45:30 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 7 Mar 2009 15:46:01 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 7 Mar 2009 15:45:59 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Jan Janak <jan@ryngle.com>
Date: Sat, 07 Mar 2009 15:45:57 -0500
Thread-Topic: [Sip] draft-state-sip-relay-attack-00
Thread-Index: AcmfXg0GObaIYznBRaOok2Fsz4+v+AAAVIDw
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC314C4DE62A5@mail>
References: <49AE593F.6080807@iptel.org> <0a8001c99d0f$0b21e210$c2f0200a@cisco.com> <49AF9FC8.2020200@iptel.org> <E6C2E8958BA59A4FB960963D475F7AC314C46BD96D@mail> <20090307195045.GC4364@x61s.janakj.ryngle.net>
In-Reply-To: <20090307195045.GC4364@x61s.janakj.ryngle.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sip@ietf.org" <sip@ietf.org>, Dan Wing <dwing@cisco.com>
Subject: Re: [Sip] draft-state-sip-relay-attack-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2009 20:45:31 -0000

> -----Original Message-----
> From: Jan Janak [mailto:jan@ryngle.com]
> Sent: Saturday, March 07, 2009 2:51 PM
>
> I am not sure I understand how accepting/not-accepting INVITEs from
> non-registered contacts makes it different, could you elaborate?

Assume Bob is bad, Alice is the victim.
The setup for the attack is such that Bob sends an INVITE to/through Alice's domain, pretending to be Alice.  Alice's domain challenges the INVITE, which Bob passes on to Alice, and using her challenge-response Bob challenge-responds to Alice's domain.  Right?

I am arguing that in common practice (in my particular market space, anyway), Alice's domain wouldn't accept Bob's spoofed INVITE to begin with.  Because it requires Bob's UA to actually be Registered as Alice in order to send in an INVITE pretending to be Alice.  Since REGISTER requests are challenged, and the digest-challenge mechanism includes the Method name in the calculation, Bob can't try to REGISTER into Alice's domain and use a challenge-response from her INVITE to do so.  Ergo, no problem.

Even for cases where they accept INVITE's from non-registering UA's (e.g, big IP-PBX SIP Trunks), my particular customer types often restrict what AoR can be claimed or allowed to make calls in from that trunk.

On the peering side, it's a different story - but the model they currently employ is a chain-of-trust, so they trust the peer to authenticate and control things in a similar fashion.  Whether that's a good idea or not is a different story, but that's the current model.  There are protection mechanisms available to prevent or at least mitigate this particular issue for peering, but I have less confidence that people use them in practice.


> I don't want to put words in Raphael's mouth, but he probably mentioned
> publicly reachable SIP providers because they typically place no
> restrictions
> on incoming calls for their users and thus this kind of attack can be
> easily
> tried with them.

Not in my experience.  They place *many* restrictions on incoming calls.  But then those are my customers, which are just a subset, and obviously my view is undoubtedly myopic because those are the types of providers that would be talking to me to begin with.  And again, whether they actually use the tools at hand I don't know.

-hadriel