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

Hadriel Kaplan <HKaplan@acmepacket.com> Tue, 10 March 2009 21:35 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 52CCF3A68CB for <sip@core3.amsl.com>; Tue, 10 Mar 2009 14:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 fZhyEOoJRdSA for <sip@core3.amsl.com>; Tue, 10 Mar 2009 14:35:51 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 518FC3A685F for <sip@ietf.org>; Tue, 10 Mar 2009 14:35:51 -0700 (PDT)
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.340.0; Tue, 10 Mar 2009 17:36:26 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 10 Mar 2009 17:36:25 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Raphael Coeffic <rco@iptel.org>
Date: Tue, 10 Mar 2009 17:36:24 -0400
Thread-Topic: [Sip] draft-state-sip-relay-attack-00
Thread-Index: AcmhZ+BVWZZUHaF4RraGNLbmaKCiiAAIfqnA
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC314E2E0A466@mail>
References: <49AE593F.6080807@iptel.org> <e4c7495a3f98d5a2a85ccf85047515f0.squirrel@www.ohlmeier.com> <20090307183313.GA4364@x61s.janakj.ryngle.net> <E6C2E8958BA59A4FB960963D475F7AC314C4DE6292@mail> <49B2F7F2.6030804@ohlmeier.org> <E6C2E8958BA59A4FB960963D475F7AC314C4DE62D4@mail> <E6C2E8958BA59A4FB960963D475F7AC314C4DE62F0@mail> <49B5006D.8050702@iptel.org> <E6C2E8958BA59A4FB960963D475F7AC314C4FAA08C@mail> <49B63B9F.9000101@iptel.org>
In-Reply-To: <49B63B9F.9000101@iptel.org>
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: Nils Ohlmeier <lists@ohlmeier.org>, "sip@ietf.org" <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: Tue, 10 Mar 2009 21:35:52 -0000

> -----Original Message-----
> From: Raphael Coeffic [mailto:rco@iptel.org]
> Sent: Tuesday, March 10, 2009 6:06 AM
> 
> Hadriel Kaplan wrote:
> 
> Forcing registrations is the path that IMS went for, I believe. But if
> you want to take advantage of this, you may have to deploy a little more
> IMS than you'd like to. 

The concept and practice of "forcing" UA's, which have AoR's belonging to a domain, to REGISTER their contact binding for those AoR's in order to make calls, has been around a lot longer than IMS has.  Invoking the "that sounds like IMS" defense is a cheap guilt-by-association argument, and not relevant.  One might as well argue that using INVITE's or RTP "is the path that IMS went for".

You keep making it sound like sending a SIP request which does not create a dialog is somehow a difficult mechanism to implement, or "forces" people to do something they don't want to.  What is it forcing?

You're looking for a means of authenticating a UA without being subject to a relay attack.  Using a different SIP Method name, which can only be initiated by the client with the credentials, and one that UA's cannot be baited to provide by random third parties, is one solution to the problem.  If you don't like the string "REGISTER", then how about "OPTIONS"?


> This reminds me of some email providers that
> require you to connect through POP3 prior to send any message through
> SMTP, instead of deploying any secure authentication mechnism.

No, this is more like a Website which offers email services requiring you to login using your credentials before letting you send.  It's not analogous to making you use POP3 because a REGISTER does not use a different protocol, and can be tied to the same connection-layer "flow" as the INVITE et al.

You may not like it, but any form of authentication by definition is more restrictive than no form of authentication.

 
> Maybe just an example: let's say you have a home SIP server, doing the
> usual least cost routing. Your least cost router might have something
> like 50 different routes. Do you want this box, or maybe your phones to
> have 50 running registrations, just for the purpose of having cheap
> calls? Well, personaly, I would prefer to just install my certificate on
> this box, and use TLS. But as very very few of those PSTN providers do
> support TLS, I cannot. By the way, there are already commercial products
> supporting this scenario.

So you have a mechanism that people don't seem to want to implement - and meanwhile you have another mechanism, which is widely implemented.  And the problem is...?

-hadriel