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

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Apr 2013 00:18:46 +0300

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 11 Apr 2013 18:18:32 +0200

> Nit/bug: Sec. 5.2.1 ends with a colon in the HTML version *only*, and is

Hi Yaron, could you please detail again such a nit? I cannot find it,
I see no errors in 5.2.1. Is it an error if 5.2.1 ends with a colon
(before the "transport" BNF)? Same occurs in 5.2.2. And why is 5.2.1
missing a paragraph?

Thanks a lot.

PS: It will take some time to me to reply your entire mail.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 11 Apr 2013 18:51:25 +0200

2013/4/10 Yaron Sheffer <[email-masked]>:

> 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.
------------------------------------------------------------------

> 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.

I agree that this subject should be improved. In fact, web browsers
allow setting user certificates for authentication in some web sites
requiring them. Most probably the same is valid for WSS connections
and then, a client certificate would be sent when connecting to a
specific WSS server.

I should investigate it a bit more. Does it sound fine?

Thanks a lot.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Apr 2013 15:17:10 +0200

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

> http://oversip.net/documentation/misc/sip_websocket/:

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
<[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 15 Apr 2013 11:28:31 +0300

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:
>>> 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.
>>> 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.
>>
>> 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
>> 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.

> 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
> 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?
>
> 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":
>
> 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
> which the user has to set his SIP information (SIP account, SIP
> proxy, SIP password...).
>
> - etc etc
>
>

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 <[email-masked]>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Apr 2013 12:53:26 +0200

2013/4/15 Yaron Sheffer <[email-masked]>:
> 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

> The second alternative you propose

> 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

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.

> 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."

> 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.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 15 Apr 2013 18:05:52 +0300

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Apr 2013 17:38:43 +0200

2013/4/15 Yaron Sheffer <[email-masked]>:
> 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.

Nothing prevents a SIP WebSocket client to request authentication for
an incoming request. Is it OK if the draft also mentions it in the
appropriate section?

> - 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.

Great. Would it be ok by mentioning such a security mechanism it in
the Security section?

> more thoroughly reviewed. I would be more than happy to review the new

Thanks a lot. We will publish a new revision with the requested improvements.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 15 Apr 2013 18:42:15 +0300

Authentication of incoming requests is important, but I was talking 
about something else: how does the client know that it is talking to the 
right server, e.g. when performing registration (I do hope there's a 
secure way to do it).

Best,
	Yaron

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Apr 2013 17:49:15 +0200

2013/4/15 Yaron Sheffer <[email-masked]>:
> Authentication of incoming requests is important, but I was talking about
> something else: how does the client know that it is talking to the right
> server, e.g. when performing registration (I do hope there's a secure way to
> do it).

Hi Yaron, let me a question please:

No one RFC describing a SIP transport (i.e. RFC 4168 "SIP SCTP
Transport") talks about this subject. May be I'm wrong but AFAIK this
it not related to the WebSocket layer but to the SIP layer, so it
should be defined for any transport in a separate document (of course
I may miss something).

Said in other words: how does a SIP TCP client know that it is talking
to the right server when performing SIP registration? RFC 3261 says
nothing about it. If such a security consideration should be defined,
why should it defined just for SIP over WebSocket?

Thanks a lot.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 15 Apr 2013 18:52:24 +0300

I feared as much. If this is not defined for SIP, then I agree it should 
not be defined just for WebSocket.

But maybe it's time the SIP community did something about it.

Thanks,
	Yaron

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Apr 2013 13:06:45 -0400

Yaron,

> not be defined just for WebSocket.

It is a difficult subject in sip, without perfect solutions.
Part of the problem is that calls are often forwarded. And much of sip 
is based on transitive trust.

There is one mechanism that does address this: RFC4916.
It is driven by a request in the reverse direction of the call.
So it can be authenticated using any of the sip mechanisms for 
authenticating the sender of requests.

> But maybe it's time the SIP community did something about it.

The above is one of the things we did.

The original authentication mechanisms in 3261 were found inadequate, 
and others have been added. Of note is RFC4474, but AFAIK it has had 
very limited deployment. RFC3325 is deployed a lot as part of 3gpp, 
though it puts a lot of trust in the infrastructure.

All of these things may be used over the websocket transport.

	Thanks,
	Paul (sipcore co-chair)

>>> about