IETF Logo Mail Archive

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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 15 April 2013 17:06 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 4ECB121F9610 for <secdir@ietfa.amsl.com>; Mon, 15 Apr 2013 10:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 04tYEzf10QF8 for <secdir@ietfa.amsl.com>; Mon, 15 Apr 2013 10:06:46 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4021F960C for <secdir@ietf.org>; Mon, 15 Apr 2013 10:06:46 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id QAu91l0030SCNGk55H6mHE; Mon, 15 Apr 2013 17:06:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id QH6l1l00i3ZTu2S3VH6laz; Mon, 15 Apr 2013 17:06:46 +0000
Message-ID: <516C33A5.3050301@alum.mit.edu>
Date: Mon, 15 Apr 2013 13:06:45 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
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> <516C2238.5000200@gmail.com>
In-Reply-To: <516C2238.5000200@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366045606; bh=ew+DRDsA2uzMFsQq/ptDk4UwXFzH3WoyOIlaCEw8Myw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r5PnDKXMf4V5A/9GErupqPbI0cF0FSUK9AwgF6XJlVzE4HcgrwAj4oCyWJpHDx4IE 9gC5Klz3J6CRuwyM+OYd6PH1953+ag9GBPMeKq3yDW9s8EXSSITJFWW/eqF19/VfR0 CFJ8K6qex+1W9xCf1Edl2yx69uXwoNLpktzsF50IEbkS2Mx8ZGZPQaDvGXTI/DAzMn g5UCMWLoAGk32ooWVXJOC6/k54rzZO+c60bkoI2EZ+VMwkR5jIxIh0BEI7QKelhYow wpSyGr0NTT4AX6N+64AkKbTZk6/y/89MgylIYqxZyHwzULDKkwznK+MVkOjJ9OJlGf obV0fZcNvydnA==
X-Mailman-Approved-At: Mon, 15 Apr 2013 10:14:19 -0700
Cc: Iñaki Baz Castillo <ibc@aliax.net>, 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 17:06:47 -0000

Yaron,

On 4/15/13 11:52 AM, Yaron Sheffer wrote:
> I feared as much. If this is not defined for SIP, then I agree it should
> not be defined just for WebSocket.

It is a difficult subject in sip, without perfect solutions.
Part of the problem is that calls are often forwarded. And much of sip 
is based on transitive trust.

There is one mechanism that does address this: RFC4916.
It is driven by a request in the reverse direction of the call.
So it can be authenticated using any of the sip mechanisms for 
authenticating the sender of requests.

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

The above is one of the things we did.

The original authentication mechanisms in 3261 were found inadequate, 
and others have been added. Of note is RFC4474, but AFAIK it has had 
very limited deployment. RFC3325 is deployed a lot as part of 3gpp, 
though it puts a lot of trust in the infrastructure.

All of these things may be used over the websocket transport.

	Thanks,
	Paul (sipcore co-chair)

>
> 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