IETF Logo Mail Archive

Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 15 April 2013 15:52 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73C121F940B; Mon, 15 Apr 2013 08:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.138
X-Spam-Level:
X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[AWL=2.161, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2L9Aqsehc5P; Mon, 15 Apr 2013 08:52:29 -0700 (PDT)
Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id BC7DE21F9305; Mon, 15 Apr 2013 08:52:28 -0700 (PDT)
Received: by mail-ee0-f49.google.com with SMTP id l10so2287701eei.8 for <multiple recipients>; Mon, 15 Apr 2013 08:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G5605tsQCuHIG+kn6QKWVTdrH8ejyIF98tM/4uCvlvo=; b=WbJopwG0tIMD+gEprpgEKk6nQ27MOz51B1BJq6gvNXnXrSVWHbLBJHs/xy7aYh1lfW MM+7r3dXdMcL0TU7zu7NpVCRVmNGZWRGajqhjNIkb3BPYhU0Xf46RP+UMlLMeHdjepRF v+IfpZ022qmKbHY9fcT10um5898d75u7b7tywq5WMSKBsOGobs2huit94OBABxHM2XMJ 1hsAmYDoWOUTJsnMVZk5Ga+QY2sMGD/C72gSyMcbLM7KU34YWF1Xaa3xG2nAZz+tE0bL oIWnIR1+7WH+6pAO4rNiNtfKcNvqm5TiJ5e/1KQkdkNX3jnIOmxxtdBH4LswoVoLYzIK xppA==
X-Received: by 10.15.83.73 with SMTP id b49mr63203238eez.25.1366041147836; Mon, 15 Apr 2013 08:52:27 -0700 (PDT)
Received: from [10.0.0.6] ([109.65.117.169]) by mx.google.com with ESMTPS id b5sm27441902eew.16.2013.04.15.08.52.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 08:52:27 -0700 (PDT)
Message-ID: <516C2238.5000200@gmail.com>
Date: Mon, 15 Apr 2013 18:52:24 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Iñaki Baz Castillo <ibc@aliax.net>
References: <5165D736.9010903@gmail.com> <CALiegfn55tepAXP2DJye6doFcd+ocY9a1oEchLLFhVo5BZf1VA@mail.gmail.com> <CALiegf=dp6veajuXNUMuVd0Re_8J-FvFiY2bqd_tzJe5uRWG=Q@mail.gmail.com> <516BBA2F.7080505@gmail.com> <CALiegfkiHxc0nCumada2kUk+dGu9o3AXCd0Gxs3MhAGnJb+UWg@mail.gmail.com> <516C1750.90505@gmail.com> <CALiegfnRmzNem9vTNnCArfyv-BnUFO6CJnmDpAK6jq8wBN80zA@mail.gmail.com> <516C1FD7.2030402@gmail.com> <CALiegfm_nX5G=S41PuaSCo8DrPgcHiPj2umE5_sYFz3753q+bA@mail.gmail.com>
In-Reply-To: <CALiegfm_nX5G=S41PuaSCo8DrPgcHiPj2umE5_sYFz3753q+bA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-sipcore-sip-websocket.all@tools.ietf.org, The IESG <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 15:52:29 -0000

I feared as much. If this is not defined for SIP, then I agree it should 
not be defined just for WebSocket.

But maybe it's time the SIP community did something about it.

Thanks,
	Yaron

On 2013-04-15 18:49, Iñaki Baz Castillo wrote:
> 2013/4/15 Yaron Sheffer <yaronf.ietf@gmail.com>:
>> Authentication of incoming requests is important, but I was talking about
>> something else: how does the client know that it is talking to the right
>> server, e.g. when performing registration (I do hope there's a secure way to
>> do it).
>
> Hi Yaron, let me a question please:
>
> No one RFC describing a SIP transport (i.e. RFC 4168 "SIP SCTP
> Transport") talks about this subject. May be I'm wrong but AFAIK this
> it not related to the WebSocket layer but to the SIP layer, so it
> should be defined for any transport in a separate document (of course
> I may miss something).
>
> Said in other words: how does a SIP TCP client know that it is talking
> to the right server when performing SIP registration? RFC 3261 says
> nothing about it. If such a security consideration should be defined,
> why should it defined just for SIP over WebSocket?
>
> Thanks a lot.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>

v2.23.0 | Report a Bug | By Email