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

Victor Pascual Ávila <victor.pascual.avila@gmail.com> Thu, 12 March 2009 16:58 UTC

Return-Path: <victor.pascual.avila@gmail.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 012BE3A69BD for <sip@core3.amsl.com>; Thu, 12 Mar 2009 09:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 UA1BgiMMcxmN for <sip@core3.amsl.com>; Thu, 12 Mar 2009 09:58:40 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 3CBE33A6BC8 for <sip@ietf.org>; Thu, 12 Mar 2009 09:58:40 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 25so378146eya.31 for <sip@ietf.org>; Thu, 12 Mar 2009 09:59:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J+TWJU2JBr0e0dCNDnuQcVYhMTxuAF3JQU6DUBu7PUE=; b=rc4KAS4rXyc0rHtCa/bW2Kb2rgFvI9jTQ/N87d+AcMqLSlDSkAIUYqVA5ZdSLFWDiY V6VN6tqAmJS3kk2Bxfk1jPlWdiqgCsOQqfB6Pc53bVjxSg4bRbx9lixeOY1/ZKz/IOPQ 2vWMvxWYojTjS1w+EFrcfPWa00wH5NbGrfWTE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XpWLxIX1HnweyIy08hh52Z7Hh3mcca0MbPFkJoA9p6afMef7Q59CASTJr6ymu8vqqF 8tj+5kbAsoCXRijxqxOkvdpgNku/LmZXCbbJDuPqOxABdpifZ5rQg3dV+smaUuizf3PR 9exxECsPLNpmcMnl2ArWKJvU6ZjvRnxhys8nU=
MIME-Version: 1.0
Received: by 10.210.131.6 with SMTP id e6mr5480744ebd.64.1236877156501; Thu, 12 Mar 2009 09:59:16 -0700 (PDT)
In-Reply-To: <2ec0d47f2557274d61ca48882a379aa1.squirrel@www.ohlmeier.com>
References: <49AE593F.6080807@iptel.org> <49B2F7F2.6030804@ohlmeier.org> <E6C2E8958BA59A4FB960963D475F7AC314C4DE62D4@mail> <E6C2E8958BA59A4FB960963D475F7AC314C4DE62F0@mail> <49B5006D.8050702@iptel.org> <E6C2E8958BA59A4FB960963D475F7AC314C4FAA08C@mail> <49B63B9F.9000101@iptel.org> <E6C2E8958BA59A4FB960963D475F7AC314E2E0A466@mail> <49B77BEB.4000501@iptel.org> <2ec0d47f2557274d61ca48882a379aa1.squirrel@www.ohlmeier.com>
Date: Thu, 12 Mar 2009 17:59:16 +0100
Message-ID: <618e24240903120959t7199623en2e265686311c090a@mail.gmail.com>
From: Victor Pascual Ávila <victor.pascual.avila@gmail.com>
To: Nils Ohlmeier <lists@ohlmeier.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "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: Thu, 12 Mar 2009 16:58:46 -0000

On Wed, Mar 11, 2009 at 2:49 PM, Nils Ohlmeier <lists@ohlmeier.org> wrote:
> Sure to create a Contact binding via an authenticated REGISTER is one
> possible solution.
> But I think this only works because you rely on the fact that REGISTERs
> are not being retargeted like INVITEs. Which then in the end means you
> simply can forget about authenticating all other requests, as long as the
> Contact or IP/port was successfully authenticated via the "one hop"
> REGISTER method (refer-to: IMS).
> The advantage of this solution is clearly that it can be easily deployed
> by hopefully most of the service providers today.
>
> But I believe the proper technical solution would be that the server
> authenticates itself in the challenge, plus adding protected informations
> to the challenge which allows the receiver of the challenge to verify that
> this challenge was/is targeted to himself.
> The dis-advantage is clearly that this would be only possible with
> extensions of the existing protocols. But we would/might gain other
> benefits by such a solution as well.

I did not follow the discussion on draft-dotson-sip-mutual-auth. Has
this work been discontinued?

http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt

Cheers,
-- 
Victor Pascual Ávila