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

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 10 April 2013 21:18 UTC

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
Precedence: list

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