Hi IÃaki, I apologize for my delayed response. Please see my comments below. I am still of the opinion that you should change the security "attitude" in the draft from descriptive (non-normative) to prescriptive. I also note below that leaving the security details essentially open also hurts the interoperability of the protocol. Thanks, Yaron On 2013-04-12 16:17, IÃaki Baz Castillo wrote: Please let me one comment more about this at the end of this mail: 2013/4/11 IÃaki Baz Castillo : 2013/4/10 Yaron Sheffer : 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". IMHO there is no a "channel binding". It may be or not, that's up to the implementor. For example an implementor could use the same WS connection and carry SIP registrations and calls from different SIP accounts over the same WS connection. Another implementor may associate (at server side) each WS connection with a SIP identity (for example the SIP identity could be provided in a URL parameter in the WS HTTP GET request, or retrieved from a Cookie in the same HTTP request). Honestly I don't think we should force a specific behavior here. When SIP is transported over TCP there is no rules in RFC 3261 stating that the endpoint is associated to the TCP connection, same here IMHO. Channel binding only applies when the layers are both secure. So TCP is not interesting here, but TLS is. The second alternative you propose (using WS information to identify the SIP entity) raises some questions: what if I have logged in (to WS) as Yaron, but then I SIP-register or SIP-invite as IÃaki? Dealing with such issues requires a policy, and you need to at least mention it. Solving these issues securely probably requires more than policy, it requires actual binding between the layers (using some TLS-generated material when setting up the SIP connection). The easiest way out is to say that there's no authentication at the WS layer. But then you also lose confidentiality. 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. IMHO we should leave this as flexible as possible. For example, as author of OverSIP (the first SIP proxy with WebSocket support) I leave the user to program it custom logic for authenticating/authorizing WebSocket connections and the SIP "layer" on top of them. From section "WebSocket authentication/authorization" at http://oversip.net/documentation/misc/sip_websocket/: ------------------------------------------------------------------ WebSocket authentication/authorization When a WebSocket client attempts to establish a WebSocket connection, OverSIP invokes user programmable callbacks. The user can there inspect parameters from the connection (including the HTTP GET request of the WebSocket handshake) in order to decide, based on any custom policy, whether to allow or deny the connection. The user can also assign custom parameters to the authorized WebSocket connection and retrieve such parameters when processing SIP requests coming through that WebSocket connection. By playing with these features several architectural solutions can be built for implementing any kind of authentication/authorization system. ------------------------------------------------------------------ This might work well for your implementation's target audience. But the RFC should allow implementers who are NOT security experts to build a secure implementation. I *think* most implementers of your draft will not be building open frameworks like your own implementation. They will be building actual UAs/servers that need to be secure. About the above subject, I strongly consider that the draft MUST NOT mandate how the implementor should authenticate/authorize WebSocket connection/authentications or how he should correlate WebSocket connections with SIP identities. If we mandate that then we are limiting web developers. There are tons of ways in WWW world for authenticating and authorizing connections/sessions, IMHO we should not mandate nothing at the WebSocket layer because that is out of the scope of the draft (which indeed just defines WebSocket as a new transport for SIP, but does not attempt to deal with WebSocket authentication/authorization). Please take into account that RFC 6455 (The WebSocket Protocol) does NOT state how authentication/authorization in WebSocket sessions should be implemented. Instead it leaves full flexibility to web developers for choosing their preferred mechanism. Why should this draft mandate that at *WebSocket* level? does RFC 3261 state something about how a SIP proxy should accept or not SIP TCP connections from certain IP addresses? The draft could mandate something like: "HTTP Digest authentication is required at WebSocket level when establishing the WS handshake, and later HTTP Digest authentication MUST be used for every SIP request over such a WS connection, and both credentials must be the same and...". That would be a big error, and that would just work if we assume that "SIP over WebSocket" is just valid for creating a pure phone in a web (out of the context of the website itself) which would just become a replacement for desktop phones or softphones. That's fully wrong. There are a lot of possible scenarios for "SIP over WebSocket": - A social network, which *already* has its login/authentication/session/authorization mechanism, could include SIP over WebSocket for enabling RTC between its users. No need for Digest auth at all since the user was *already* logged in the web site and thus the server(s) can correlate the HTTP session with the WebSocket connection (via Cookies, a custom token or whatever). - Another web site could provide a "Web <--> PSTN" application in which the user has to set his SIP information (SIP account, SIP proxy, SIP password...). - etc etc So, I strongly think that the draft is correct in this subject. Mandating how authentication must be done would limit the scope of this SIP transport and would make it 100% unusable for most of the existing web deployments. I agree that it would be a mistake to mandate a specific auth mechanism for SIP or for WS. I think you should mandate that (any) such mechanism be used (and maybe give a few examples). And you should provide tools (like a header, a cookie format...) to build the correlation. Please also note that leaving these details open means that effectively, you will not have interoperability. You might want to consider mandating some minimal mechanisms so that you can have an interoperable *and* secure baseline. Best regards. -- IÃaki Baz Castillo