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