[secdir] SecDir review of draft-ietf-sipcore-sip-websocket-08
Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 10 April 2013 21:18 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 A4F5121F8F03; Wed, 10 Apr 2013 14:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 XYdT6PuRM-zq; Wed, 10 Apr 2013 14:18:53 -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 B3C3221F8F02; Wed, 10 Apr 2013 14:18:52 -0700 (PDT)
Received: by mail-ee0-f49.google.com with SMTP id l10so443680eei.22 for <multiple recipients>; Wed, 10 Apr 2013 14:18:51 -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:subject :content-type:content-transfer-encoding; bh=qsDgVFZF+NT7vdL9ctsdIwiYyvsWR4J6DWd1Wg+aKFc=; b=MPiKHNEdgFkeIllxk0OwDUoe91EkVn6GdNmAc65zi2Nl2rB4JCIC/kBztR00H33FUM FtPIroNMtqhGGKlmUGV+a0DipOrW/yfSHZ8n1qfFF7KRLKMHlWnchHLUId3z4zF/wpzk KUKWH0cAN+jhIgcvAul8g/XWAla6DCGlVCHgWgRINaKlmX5YhJIGEPV6Nr7lGZjx+DgH idxUPIitJKSoIoKl/rVKVogOxZZffsW4Yolk6up+DLvDyGIhlNStks+l9jWiQVWOIkMS 9vrfiRTT4eSwXUZO3135Ya2Ke2XoBwS3OfrWuVgkq9cwbCe/t7v8x8lkAYH6K7dl9BkO fOVg==
X-Received: by 10.14.181.196 with SMTP id l44mr2108474eem.44.1365628731723; Wed, 10 Apr 2013 14:18:51 -0700 (PDT)
Received: from [10.0.0.7] ([109.64.136.230]) by mx.google.com with ESMTPS id a2sm599782eem.11.2013.04.10.14.18.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 14:18:50 -0700 (PDT)
Message-ID: <5165D736.9010903@gmail.com>
Date: Thu, 11 Apr 2013 00:18:46 +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: IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-sipcore-sip-websocket.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [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: Wed, 10 Apr 2013 21:18:53 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines how SIP can be layered on the WebSocket protocol. This is essentially a profile of SIP. Summary In my opinion, from a security perspective this document is not yet ready for publication. I expect this document to be widely implemented, and I would not want it implemented until it offers a solid security model, even if it is optional. Details RFC 3261 has 20 pages of security considerations, and defines several security mechanisms. The current document "only" defines a transport for SIP, but such transport needs to preserve the security of any SIP mechanisms being used. In particular, it should be clear how endpoint identities are determined at each layer and how identities at different layers relate to one another. In other words, what's known as "channel binding". The only security-related section (other than the Security Considerations) is Authentication (Sec. 7), and this section is marked non-normative. So the reader is left to wonder: how is the SIP client authenticated? How does this authentication relate to the WebSocket-level client authentication? And similarly for the server. Sec. 9.1 mentions (again, non-normatively) that SIP-level certificate checks are omitted, and replaced by transport-level checks only. I believe this significantly reduces the security properties of SIP. Moreover, it begs for a policy tying WebSocket certificates to identities of the endpoints of the SIP protocol. Nit/bug: Sec. 5.2.1 ends with a colon in the HTML version *only*, and is missing a paragraph. Thanks, Yaron
- [secdir] SecDir review of draft-ietf-sipcore-sip-… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Iñaki Baz Castillo
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Iñaki Baz Castillo
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Iñaki Baz Castillo
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Iñaki Baz Castillo
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Iñaki Baz Castillo
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Iñaki Baz Castillo
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-sipcore-… Paul Kyzivat