IETF draft-sterman-aaa-sip-04 describes a mechanism for RADIUS servers to participate in a SIP DIGEST challenge/response without the SIP proxy having a copy of the password or HA1 value at all. This is implemented by the FreeRADIUS project in the module rlm_digest and supported by all the major SIP proxy servers.

At the time of writing, work is in progress to enable RADIUS to participate in TURN authentication in the same way.


If LDAP is in use, you may wish to consider storing the HA1 values in the LDAP directory. Each time a user is created or a user changes their password, the LDAP server will need to update the HA1 hash as well as updating any other copies of the password hashed with other algorithms.

For example, the OpenLDAP server allows such logic to be implemented in an overlay, this is already demonstrated in the smbk5pwd module for hashing copies of the user's password in various algorithms used by Windows.

Due to the sensitive nature of the HA1 values, they should be stored in an attribute that is not readable to any other user or anonymous access. Example 7.2, “OpenLDAP ACL for protecting ha1Password demonstrates how to protect the ha1Password so it can only be read by a user cn=sip-proxy,dc=example,dc=org.

Example 7.2. OpenLDAP ACL for protecting ha1Password

    access to attr=ha1Password
        by self =xw
        by dn="cn=sip-proxy,dc=example,dc=org" read
        by anonymous auth
        by * none 

LDAP can also be used to assist in routing as described in Chapter 15, Adding ENUM to DNS.

SQL databases

Many RTC products have some capability to interact with an SQL database to obtain user credentials, configuration settings and routing information. Example 7.3, “SQL table for repro users” demonstrates a typical schema.

Example 7.3. SQL table for repro users

  username VARCHAR(64) NOT NULL,
  domain VARCHAR(253),
  realm VARCHAR(253),
  passwordHash VARCHAR(32),
  passwordHashAlt VARCHAR(32),
  name VARCHAR(256),
  email VARCHAR(256),
  forwardAddress VARCHAR(256)

Each product has a different schema, however, it is possible to create a user list table that aggregates all the columns required to satisfy multiple processes and then create SQL views to present the data with the column names required by the individual applications. For example, a single user list table can be created for use by Asterisk (the sippeers table) and used by repro (using a view instead of a real users table) as demonstrated in Example 7.4, “SQL view presenting Asterisk users to repro”. repro simply doesn't require many of the columns used by Asterisk. Notice that Asterisk's sippeers table doesn't contain a domain or realm column for each user, these are stored elsewhere in the sip.conf file, so for repro, they are specified as constant values in the SELECT query.

Example 7.4. SQL view presenting Asterisk users to repro

    name AS username,
    'my_domain' AS domain, 
    'my_realm' AS realm,
    md5secret AS passwordHash,
    NULL As passwordHashAlt,
    NULL AS name,
    NULL AS email,
    NULL AS forwardAddress
  FROM sippeers;

Setting up PostgreSQL for SIP users

The packages for the repro SIP proxy include SQL schema files for creating tables. Example 7.5, “Install PostgreSQL on Debian or Ubuntu” demonstrates how to install the PostgreSQL server package. Example 7.6, “Configure PostgreSQL and load schema” demonstrates how to use the createdb command to create a database called repro and use the psql command to log in as the DBA and create a user called repro for the SIP proxy. The final psql command uses the schema file to create the tables.

Example 7.5. Install PostgreSQL on Debian or Ubuntu

$ sudo apt-get install postgresql postgresql-client

Example 7.6. Configure PostgreSQL and load schema

$ sudo su - postgres
postgres$ createdb repro
postgres$ psql
postgres=# create user repro password 'abc';
postgres=# \q
postgres$ exit
$ su vi /etc/postgresql/9.4/main/pg_hba.conf
$ su systemctl restart postgresql
$ psql -U repro -W repro < /usr/share/doc/repro/create_postgresql_reprodb.sql

Product-specific file formats

Each product also supports some native file formats. For example, repro can store user data in Berkeley DB files while Asterisk can store users in the sip.conf text file. The Prosody XMPP server can store its data in JSON files. In some cases, the files are maintained by the administrator using a text editor and in other cases they are updated at runtime by the application.

To eliminate the risk of runtime dependencies on databases, it is relatively straightforward to create a script that periodically extracts user data from a database and creates files for the relevant processes to consume. If one of the processes has to start up or continue operating during a database outage, it will be able to do so using the last copy of the file.