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

Iñaki Baz Castillo <ibc@aliax.net> Mon, 15 April 2013 15:39 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 4BD0121F93EE for <secdir@ietfa.amsl.com>; Mon, 15 Apr 2013 08:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.057
X-Spam-Level:
X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.620, 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 8J-zcPWzIuZu for <secdir@ietfa.amsl.com>; Mon, 15 Apr 2013 08:39:04 -0700 (PDT)
Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id B901E21F93E9 for <secdir@ietf.org>; Mon, 15 Apr 2013 08:39:04 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id 6so2743284qeb.22 for <secdir@ietf.org>; Mon, 15 Apr 2013 08:39:04 -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=FujVlplovB6uzvAyUbOD+r9Y3UPVVzUnPQ/4Q0JB5ss=; b=pKYVjZsSotXRMV352zq43PC9JVZuCqm7UGp/8wuntEGieXhP9xkSuk2LPZYq7mBJCp Kh0xRYAlHR55+zhEnX4HBAo2dWxRR3qRSMpJQdVhSy+PcbDywl3SRWSf6EvBcEfAdu2X xEpYGCOA9NrDtcQGFpgrH3lDtvK1dUUvq2kL2NjUDMKO0ikEz5thhy3ygdGHh1vWoa+w 1rX8iTMy2VLZS1TVgna9rczxwYkzmUqUv/ASBXcHjaY3x2NpNlcwscL6s7tyzX3M8KHS zAGBghjWauSNkxl7kbHGc9PlD7kMAgCu2U/VPHg5hR1/0rkcXMRIArhgYHA95Z5nKYpX aHLw==
X-Received: by 10.224.53.11 with SMTP id k11mr23005299qag.3.1366040344204; Mon, 15 Apr 2013 08:39:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.81.175 with HTTP; Mon, 15 Apr 2013 08:38:43 -0700 (PDT)
In-Reply-To: <516C1750.90505@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>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 15 Apr 2013 17:38:43 +0200
Message-ID: <CALiegfnRmzNem9vTNnCArfyv-BnUFO6CJnmDpAK6jq8wBN80zA@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: ALoCoQmM5nDcaaBXncKHM0+Xwu/QMhBpRp30WFMCbg9X5aiXJ4nyO0XsCS0m7yRA8VXj2bbbHjbD
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:39:05 -0000

2013/4/15 Yaron Sheffer <yaronf.ietf@gmail.com>:
> Hi again,
>
> Yes, I agree with your plan for moving forward. A few remaining comments:
>
> - Unless I missed something, you only talked about authentication of the
> client, and did not mention authentication of the server to the client. From
> the point of view of the client (and customer?) this is just as important.

Nothing prevents a SIP WebSocket client to request authentication for
an incoming request. Is it OK if the draft also mentions it in the
appropriate section?



> - Unfortunately we rarely have usable client auth with TLS. I wish we had
> something better than client certificates. In fact there are some
> implementations of RFC 5054 out there, and it would be great if you could
> accommodate them as well.

Great. Would it be ok by mentioning such a security mechanism it in
the Security section?



> - I would advise you take the draft back to the WG to have these changes
> more thoroughly reviewed. I would be more than happy to review the new
> draft, too.

Thanks a lot. We will publish a new revision with the requested improvements.



--
Iñaki Baz Castillo
<ibc@aliax.net>