IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Mon, 15 April 2013 15:49 UTC

Return-Path: <ibc@aliax.net>
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 5C66621F940A for <secdir@ietfa.amsl.com>; Mon, 15 Apr 2013 08:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level:
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 esdhAwTLq6DH for <secdir@ietfa.amsl.com>; Mon, 15 Apr 2013 08:49:36 -0700 (PDT)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 99BE921F940D for <secdir@ietf.org>; Mon, 15 Apr 2013 08:49:35 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id b40so358011qcq.11 for <secdir@ietf.org>; Mon, 15 Apr 2013 08:49:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=FGwCXStMnJpRv7+OP8ftjM/5s65E+FrMqq3EGIqMoBQ=; b=f+GRf/lZr43aseOi3QCm7/vn07CgYt6U+E7TzLGRmDmvPV44V53XQmrGsybDmVuBwJ roXc/mIaPPh6H8EMNnorHcLf9rCAsiTaPIoXJCAKDB7u9rjmZFCMVgMNXpW08Bwz3V6d d46uXkL6OxkPFk6WE1OZKbZWpVTslTOxgiKVEiJbFEW3oATsDkuurbJdkWQyl5EDCEhu fHVYqK09AjFNiRCqaBw+PRBtNKjDcTbNkLM1fNWlqn1trc65CvQOCILYNOD1Rl0Gd/1N 7p3OdKtnK6osRnJxPvBQi1Fx19TrhIvqYHPDiYmqNqihRzcBNubwmoskDM92ClZyPq4Q jIJA==
X-Received: by 10.49.104.196 with SMTP id gg4mr26666246qeb.53.1366040975058; Mon, 15 Apr 2013 08:49:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.175 with HTTP; Mon, 15 Apr 2013 08:49:15 -0700 (PDT)
In-Reply-To: <516C1FD7.2030402@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>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 15 Apr 2013 17:49:15 +0200
Message-ID: <CALiegfm_nX5G=S41PuaSCo8DrPgcHiPj2umE5_sYFz3753q+bA@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkyqGKIA+Nu5rmku9EfkMo/CzfZRzLU9TPJOC1cgz+uj6lvMy44mo5HykMgs35HYwllMRd2
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:49:36 -0000

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