[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