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

[Iñaki Baz Castillo <[e-mail]>]

Please let me one comment more about this at the end of this mail:



2013/4/11 Iñaki Baz Castillo <[e-mail]>:
> 2013/4/10 Yaron Sheffer <[e-mail]>:
>
>> 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.
>
>
>
>> 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.
> ------------------------------------------------------------------


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.


Best regards.



--
Iñaki Baz Castillo
<[e-mail]>