Skip to main content

Last Call Review of draft-ietf-sipcore-sip-websocket-08
review-ietf-sipcore-sip-websocket-08-secdir-lc-sheffer-2013-04-11-00

Request Review of draft-ietf-sipcore-sip-websocket
Requested revision 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 Baz Castillo , Jose Luis Millan , Victor Pascual
I-D 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
Request Last Call review on draft-ietf-sipcore-sip-websocket by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 10)
Result Has issues
Completed 2013-04-11
review-ietf-sipcore-sip-websocket-08-secdir-lc-sheffer-2013-04-11-00
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