Difference between revisions of "SIP Over WebSocket Cookies"

From reSIProcate
Jump to navigation Jump to search
Line 34: Line 34:
 
*** The values are used to specify the URIs the caller is permitted to call and the identities the caller is permitted to use in the "From" header
 
*** The values are used to specify the URIs the caller is permitted to call and the identities the caller is permitted to use in the "From" header
 
*** The asterisk symbol can be used as a wildcard in the URIs in this header
 
*** The asterisk symbol can be used as a wildcard in the URIs in this header
*** The exact values are: time:expiry:fromURI:toURI
+
*** The exact values are: time0:expiry:fromURI:toURI
 +
**** time0 is the timestamp when the cookie was created, expiry is the timestamp for expiry, both are in UNIX seconds since 1 Jan 1970
 +
**** fromURI and toURI are URIs such as bob@example.org or *@example.org (using * as a wildcard), sip scheme prefix is not necessary
 
** '''WSSessionExtra'''
 
** '''WSSessionExtra'''
 
*** This is an arbitrary value that can be used for any purpose in the SIP proxy or application
 
*** This is an arbitrary value that can be used for any purpose in the SIP proxy or application

Revision as of 14:06, 19 December 2013

Overview

Transport level

  • When a WebSocket client connects, the browser sends cookies in the HTTP Upgrade request, before sending any SIP messages over the connection
  • All individual cookie names and values are stored by the WsConnectionBase object
  • Furthermore, there are some special cookies that reSIProcate recognises, if the transport sees these cookies, it constructs an instance of WsCookieContext
    • They are WSSessionInfo, WSSessionExtra, WSSessionMAC
  • If the special cookies are found and if a connection validator has been provided, it will be asked to check the cookies. At this point, if the check is unsuccessful, the connection is dropped before any SIP messages can be passed.
    • A sample connection validator is included in the repro SIP proxy but it could be used in any other application. The sample connection validator is based on the concept of a shared secret, timestamps and a HMAC, details below.

SIP Messaging

  • Each time a SIP message is received over a WebSocket connection, the raw cookies and the WsCookieContext (if the special cookies were found) are copied from the connection into the SIP message and they are accessible using the methods SipMessage::getWsCookies() and SipMessage::getWsCookieContext()
  • The reSIProcate stack itself makes *no low-level checks* on the contents of the cookies at the time a message comes into the transport, not even the special cookies in WsCookieContext. It is up to the application to make any checks for authorisation or routing purposes.
    • The Dialog Usage Manager(DUM) includes an authentication module WsCookieAuthManager that can be used for authentication in dialogs (for example, when building a B2BUA or when the repro SIP proxy is handling a REGISTER request). The algorithm used, based on the WsCookieContext special cookies, is described below. Applications wanting to use this mechanism need to explicitly instantiate WsCookieAuthManager and add it to the master profile.
    • The repro SIP proxy includes a monkey called CookieAuthenticator based on the same algorithm that is described below with WsCookieContext special cookies.
  • It should be emphasized that cookie headers are *not* present in any SIP message itself. The cookies accessible through SipMessage::getWsCookies() are cached from the moment the HTTP connection started. They are accessed through the SipMessage API for convenience only.
    • One effect of this is that the cookies are not transmitted by the SIP proxy to any other SIP endpoint down the line. Anybody who wants to send special values from the browser to be relayed by the proxy should use [[1]] in the SIP message rather than cookies. The cookie algorithm described below provides a basic facility to authenticate the content of a special extension header using the same HMAC and shared secret that are used in authentication.

The reSIProcate WsCookieContext authentication scheme

  • This is a basic scheme similar to the HMAC signed cookie or hidden form field used by shopping carts
  • There is a risk of replay, therefore,
    • the cookie should ONLY be transferred over a secure HTTPS (TLS) connection.
    • the cookie includes an expiry time, suitably short values should be selected
  • The cookies are:
    • WSSessionInfo
      • This cookie is a series of values separated by semi-colons
      • The values are used to specify the URIs the caller is permitted to call and the identities the caller is permitted to use in the "From" header
      • The asterisk symbol can be used as a wildcard in the URIs in this header
      • The exact values are: time0:expiry:fromURI:toURI
        • time0 is the timestamp when the cookie was created, expiry is the timestamp for expiry, both are in UNIX seconds since 1 Jan 1970
        • fromURI and toURI are URIs such as bob@example.org or *@example.org (using * as a wildcard), sip scheme prefix is not necessary
    • WSSessionExtra
      • This is an arbitrary value that can be used for any purpose in the SIP proxy or application
      • (not yet implemented) The user may also send this value in an extension header in their SIP messages, the header must be called X-WS-Session-Extra and the value must be identical to the value in the cookie. This way, the value can be relayed to other systems in the SIP network.
    • WSSessionMAC (a message authentication code in hexadecimal)
      • The HMAC-SHA1 scheme is used
      • The secret is simply a single shared secret, shared between the web application and the repro proxy
      • The text to be signed is formed by concatenating the values of the other two cookies with a semi-colon separator:
        • data = WSSessionInfo:WSSesionExtra
  • The whole scheme is demonstrated in a basic PHP example, the source code is in websocket-cookie-test.php