Last Call Review of draft-ietf-sipcore-sip-websocket-08

Request Review of draft-ietf-sipcore-sip-websocket
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-04-15
Requested 2013-04-04
Authors Inaki Castillo, Jose Millan, Victor Pascual
Draft last updated 2013-04-11
Completed reviews Genart Last Call review of -08 by Suresh Krishnan (diff)
Genart Telechat review of -08 by Suresh Krishnan (diff)
Secdir Last Call review of -08 by Yaron Sheffer (diff)
Assignment Reviewer Yaron Sheffer 
State Completed
Review review-ietf-sipcore-sip-websocket-08-secdir-lc-sheffer-2013-04-11
Reviewed rev. 08 (document currently at 10)
Review result Has Issues
Review completed: 2013-04-11


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.


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.


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 


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.