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.
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
CREATE TABLE users ( id SERIAL PRIMARY KEY, 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
CREATE VIEW users AS SELECT id, 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;
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
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.