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

[Yaron Sheffer <[e-mail]>]

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 <[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.
>>
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 <[e-mail]>
>