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

Raphael Coeffic <rco@iptel.org> Mon, 16 March 2009 09:45 UTC

Return-Path: <rco@iptel.org>
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 22AEB3A698E for <sip@core3.amsl.com>; Mon, 16 Mar 2009 02:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.405
X-Spam-Level:
X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 pQs85r0H9HYF for <sip@core3.amsl.com>; Mon, 16 Mar 2009 02:45:45 -0700 (PDT)
Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id E6E063A6A6F for <sip@ietf.org>; Mon, 16 Mar 2009 02:45:44 -0700 (PDT)
Received: by mail.iptel.org (Postfix, from userid 103) id A1EB51810C68; Mon, 16 Mar 2009 10:46:25 +0100 (CET)
Received: from rco-imac.local (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTPSA id 7AC3F1810C68; Mon, 16 Mar 2009 10:46:24 +0100 (CET)
Message-ID: <49BE1FEF.4020008@iptel.org>
Date: Mon, 16 Mar 2009 10:46:23 +0100
From: Raphael Coeffic <rco@iptel.org>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
References: <49AE593F.6080807@iptel.org> <49BBA27C.4050805@cisco.com>
In-Reply-To: <49BBA27C.4050805@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
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: Mon, 16 Mar 2009 09:45:46 -0000

Jonathan Rosenberg wrote:
> Raphael and others,
>
> Thanks for putting this together.
>
> Considering for a moment figure 1, this attack is possible only if UAs 
> accept incoming requests from any place, and not just their proxy. In 
> practice, this is seldom allowed. Indeed, if it is allowed, there are 
> worse attacks than this which can be launched (free phone calls, spam 
> calling, etc.). Using the SIP recommended TLS between UA and proxy 
> also mitigates that.
>
That's right, and also the reason we called this the basic attack. Using 
TLS would be indeed a good choice, unfortunately, only few providers do 
offer it to their customers (but of course, only for the small panel I 
know of, and those I use).

> So really figure 2 is the interesting one. However, this attack 
> assumes that Alice has credentials on multiple systems. Again, in 
> practice, this is extremely uncommon. Certainly none of the existing 
> deployed enterprise or service provider consumer deployments are of 
> this nature.
I understand that this might not be a common case, as the common case is 
more focused on a vonage (or alike) customer, receiving a 
ready-configured phone that just has to be pluged into the residential 
gateway. However, a lot of SIP freaks like us do have a lot of 
configured accounts on the same phone, and not only for test purposes. 
For my part, my home phone is connected with 3 accounts: one default 
(PSTN), my iptel.org account, and another provider that own one of our 
PSTN numbers (only inbound).

I have seen one year ago an application for a residential gateway 
implementing a SIP least cost router. It was available as an unofficial 
upgrade for a very popular type of resential gateway. In the case, the 
configuration was at its minimum: all the required config was downloaded 
by the least cost router application. All you had to do was to create 
some accounts at some PSTN provider, and configure them into the box, 
which would do the rest.

I can believe that this kind of application could become more popular, 
just like they were in the PSTN.

>
>
> As such, I dont think this attack is likely in practice. However, in 
> theory it is possible. The essence of the attack is that the victim is 
> providing credentials to an unauthenticated server (since the attacker 
> is acting like a server, asking for credentials). In that way, as 
> others have pointed out, it is similar to baiting attacks that have 
> been previously documented. With SIP it is most easily remedied by a 
> rule which says, 'don't pass credentials for domain X to a server that 
> is not domain X'.
Which means that you exclude any relays in between. I think it also 
implies reverse DNS lookups, right?

> Server identity can be verified by normal server-only auth between a 
> client and its server, but even that is not needed. 
Right, mutual authentication seems to be the best way.

> A client will know which domain its proxy is representing, and once 
> connected, it only provides credentials for that domain.
>
What do you mean by "connected"? And why should a UA only provide 
credentials for one domain only?
Is that about TCP or SCTP connections? and providing only credentials 
for a particular domain on a particular connection?

-Raphael.