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

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



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