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

[Yaron Sheffer <[e-mail]>]

Hi again,

Yes, I agree with your plan for moving forward. A few remaining comments:

- Unless I missed something, you only talked about authentication of the 
client, and did not mention authentication of the server to the client. 
 From the point of view of the client (and customer?) this is just as 
important.

- Unfortunately we rarely have usable client auth with TLS. I wish we 
had something better than client certificates. In fact there are some 
implementations of RFC 5054 out there, and it would be great if you 
could accommodate them as well.

- I would advise you take the draft back to the WG to have these changes 
more thoroughly reviewed. I would be more than happy to review the new 
draft, too.

Thanks,
	Yaron

On 2013-04-15 13:53, Iñaki Baz Castillo wrote:
> 2013/4/15 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.
>
>
> Hi Yaron, thanks a lot for your detailed response. Before inline
> replies please let me expose some examples of SIP over WebSocket:
>
>
> Case 1)
>
> This is a real case: Asterisk PBX also implements SIP WebSocket
> transport. This implementation is 100% website agnostic as it just
> requires the SIP WS client to connect to Asterisk IP and port 8088 (or
> the TLS version) and set "/ws" in the URL of the WebSocket HTTP GET
> request handshake. It does not care at all about the website
> domain/origin in which the JavaScript SIP WebSocket client is running.
> And finally Asterisk requires SIP Digest authentication for any SIP
> request coming over WebSocket connections (unless the "peer" has been
> configured with "insecure=invite,port" per local policy).
>
> This is obvisouly the simplest usecase in which Web / WebSocket stuff
> is irrelevant for the proxy/PBX, which just exposes a WebSocket
> interface but does not care about web logins, web sessions or whatever
> WWW related stuff.
>
>
> Case 2)
>
> A telco PSTN provider may offer a website in which its clients login
> with some web user account. The provider does not want to expose the
> client's SIP password in the web for security/privacy reasons. Once
> the user is logged, the Web server returns a Cookie containing a SIP
> identity and a session token string to the JavaScript application. The
> JS app opens then a WebSocket connection to a SIP WebSocket server by
> attaching the Cookie in the WebSocket HTTP handshake request. The SIP
> WebSocket server inspects the session token in the Cookie and
> retrieves from a database the SIP identity such a web session is
> associated to. The SIP WebSocket server requires that any SIP request
> coming from that WebSocket connection has a From header containing
> such a SIP identity. Otherwise it rejects the request and, optionally,
> closes the WebSocket connection (as it seems there is a CLI spoof
> attempt).
>
>
> Case 3)
>
> Same as case 2, but in this case the WebSocket URI has a
> domain/subdomain which does not match the domain of the Web server
> from which the WS SIP client has been retrieved and, thus, the usage
> of Cookies is not allowed. In this case the Web server returns some
> kind of session token string after the user performs the web login
> procedure. The WS SIP JavaScript app makes the WebSocket connection by
> adding such a session token string as a SESSION_TOKEN query parameter
> value in the WebSocket GET request. The SIP WebSocket server reads it
> and looks for its value in a DB in which the Web server stored each
> session token and the user profile it belongs to.
>
>
>
> Case 4)
>
> Some as case 2 or case 3, but the SIP WebSocket server will also
> request SIP Digest authentication from every request.
>
>
>
> Considering the above four examples, let me please reply inline to
> your comments:
>
>
>
>
>
>>> 2013/4/11 Iñaki Baz Castillo <[e-mail]>:
>
>>>> 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).
>
>
>> 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?
>
> In case 1 above, this does not apply since there is no Web/WS login.
>
> In cases 2 and 3, the SIP WebSocket server would reject the SIP
> REGISTER since the SIP AoR being registered does not match the SIP
> identity associated to this WebSocket connection.
>
> In case 4 the SIP WebSocket could also reject the REGISTER, or may be
> not since auth at SIP level will be also requiered by the server.
>
>
>
>
>
>> Dealing with such issues requires a policy, and you
>> need to at least mention it.
>
> The problem I see is: how to mention a policy that cannot be applied
> for every case? As said above, case 1 does not deal at all with
> Web/WebSocket login/session stuff.
>
>
>
>>   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).
>
> Let me please address the above subject without adding TLS. This is,
> let's assume non secure WebSocket connections for the four cases
> above. Do you agree that it is not possible to mention a policy due
> the differences between the use cases? Of course the draft may mention
> more deeply the different authentication/authorization scenarios, but
> I cannot imagine a policy with a MUST since some of the above 4
> scenarios would be invalidated.
>
>
>
>
>
>>>> ------------------------------------------------------------------
>>>> 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.
>
>
> I understand your concerns but, which kind of policy could the draft
> mandate without invalidating some of the use cases above?
>
> What about if the draft mandates "some" kind of authentication? For example:
>
>
>
> "If SIP Digest authentication is not requestes, then the SIP WebSocket
> server MUST authorize SIP requests based on a previous Web or
> WebSocket login / authentication procedure, and MUST validate the SIP
> identity in SIP requests by matching it with the SIP identity
> associated to the WebSocket session. If no authentication is done at
> WebSocket level then SIP Digest authentication is required for every
> SIP requests coming from the WebSocket connection."
>
>
>
>
>
>>> 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.
>
> Ok, that would be indeed an useful improvement for the draft. So
> please let me suggest the following sections / changes in the draft to
> satisfy this need:
>
>
> - Some kind of non-normative new section called "Use Cases" in which
> something like the above four examples would be mentioned.
>
> - Changes to the "Authentication" section which would become normative
> and would mandate "some kind of authentication", may be in WS layer
> and/or SIP layer, and would also mandate some kind of
> "authorization/validation" of SIP requests in case the authentication
> was done at WS layer.
>
> - A new subsection under "Authentication" section called "Client TLS
> Authentication": If the SIP WS Client provides a valid TLS certificate
> during the WS handshake (and the SIP WebSocket server alows client
> authentication based on TLS certificates) then the server may inspect
> the SIP identity in such a certificate and then require that SIP
> requests from that WS connection MUST contain such a SIP identity
> (otherwise the server could choose whether to just reject the request
> with 403, or request SIP Diget authentication, or close the WS
> connection).
>
>
>
>
>
>> 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.
>
> IMHO we cannot mandate how Web developers must implement login
> procedures in their websites. There are tons of mechanisms for that
> purpose, and it should be possible that all those mechanisms can be
> reused when adding SIP over WebSocket capabilities to a website.
>
> When we talk about "interoperability" and "SIP over WebSocket" I think
> we should consider that:
>
> - WebSite developers build the WWW server side (the Web server and
> logic) along with the client side (the HTML and the JavaScript app to
> be executed in the browser). Typically a JS app (I'm not talking about
> a JS library) is just designed to run against a specific web site (the
> JS code is custom per web site).
>
> - Web / WebSocket authentication can be done in tons of ways.
> Mandating a specific one would break existing scenarios.
>
> - A SIP WS library (i.e. JsSIP or SipML5) should be flexible enough to
> allow setting any URL path and custom URL params in the WS handshake
> request, and MUST implement SIP Digest. Then the web developer would
> integrate such a library within his website and would choose the auth
> mechanism he prefers.
>
> - By satisfying this previous point, and SIP WebSocket client could
> interoperate with any SIP WebSocket server that does not require
> Web/WebSocket authentication (case 1 above). When Web/WebSocket login
> is also required then we cannot mandate "interoperability" since it is
> up to the website developer how to implement the authentication
> procedure, which means that the SIP WS JavaScript app should be
> integrated into such a aspecific website by the web developer
> responsible of that web site.
>
>
> If there was agreement in these previous considerations, is it ok if I
> performs the additions and changes in the draft exposed in a previous
> paragraph of this mail?
>
>
>
> Thanks a lot for all.
>
>
>
>
>
>
>>
>>
>>>
>>>
>>> Best regards.
>>>
>>>
>>>
>>> -- Iñaki Baz Castillo <[e-mail]>
>>>
>>
>
>
>
> --
> Iñaki Baz Castillo
> <[e-mail]>
>