RADIUS

Table of Contents Overview Setting up FreeRADIUS for testing Setting up the host running repro or your own reSIProcate-based application Troubleshooting Development notes

Overview

• Benefits of using RADIUS:
  • computation and validation of digests is performed in the RADIUS server, the SIP server does not need to have copies of any user credentials, this makes it significantly harder for an attacker who compromises the SIP server to gain access to user credentials
  • rapid integration with existing RADIUS systems
  • centralised control and audit of user accounts
• RADIUS support is present at two levels
  • in the repro SIP proxy server, allowing system administrators to quickly deploy a SIP proxy with RADIUS support
  • in the Dialog Usage Manager (DUM) class RADIUSServerAuthManager.cxx which allows developers of B2BUAs, SBCs and other SIP server endpoints to offer RADIUS integration
• the RADIUS implementation implements the RADIUS Extension for Digest authentication (IETF draft-sterman-aaa-sip)
• this is known to interoperate with the rlm_digest module in the popular FreeRADIUS server
• Using RADIUS for TURN and reTurn server is not quite the same as supporting SIP.
  • SIP uses MD5 DIGEST authentication whereas TURN uses HMAC.
  • draft-sterman-aaa-sip and rlm_digest only support MD5 DIGEST.
  • Daniel Pocock has begun an rlm_hmac module for FreeRADIUS that can provide the server side for TURN authentication.
  • Discussion on the freeradius-users mailing list has suggested the use of long extended attributes instead, this is also discussed in much more detail in github pull request 367 for FreeRADIUS

Setting up FreeRADIUS for testing

• Install the FreeRADIUS package (for example, the Debian package available here can be installed using the apt-get utility)
• Symlink the default configuration into sites-enabled:

 # ln -s /etc/freeradius/sites-available/default /etc/freeradius/sites-enabled

• Add a sample user to /etc/freeradius/users

 1001    Auth-Type := Digest, User-Password = "test"

• Make sure /etc/freeradius/clients.conf allows connections from the host where your repro instance will run, for example:

 client 192.168.1.5 {
    secret = testing123
 }

Setting up the host running repro or your own reSIProcate-based application

• install the freeradius-client library and sample configuration, using the packages is the most expedient way to do this
• create a dictionary file for SIP:

 cat /etc/radiusclient/dictionary /etc/radiusclient/dictionary.sip > \
         /etc/repro/radius-dictionary
 echo "VALUE Service-Type      Sip-Session      15" >> \
         /etc/repro/radius-dictionary

• Create a copy of the RADIUS client configuration files:

 cp /etc/radiusclient/radiusclient.conf /etc/repro

• modify some of the following to suit your needs in your /etc/repro/radiusclient.conf:

 authserver some-host
 acctserver some-host
 servers /etc/repro/radius-servers
 dictionary /etc/repro/radius-dictionary
 seqfile /var/run/repro/radius.seq

• copy the server definition file:

 cp /etc/radiusclient/servers /etc/repro/radius-servers

• modify /etc/repro/radius-servers to include the server name and the secret from /etc/freeradius/clients.conf

 some-server testing123

• modify the following settings in /etc/repro/repro.config:

 DisableAuth = false
 EnableRADIUS = true
 RADIUSConfiguration = /etc/repro/radiusclient.conf

Troubleshooting

• Enable verbose logging on the RADIUS server or run it in the foreground

 /usr/sbin/freeradius -X

• Test your connection from the repro host to the RADIUS server using the radclient test utility as demonstrated in the rlm_digest documentation
• Enable verbose logging on repro, grep for RADIUS
• Use a packet sniffer like Wireshark or tcpdump to observe the RADIUS packets on the wire

Development notes

• Please see Improving RADIUS Support for a more thorough analysis of further work required in the RADIUS code
• The current implementation is not highly optimized
  • it creates a thread to process each RADIUS request
  • a slightly more efficient model would use a pool of worker threads
  • as RADIUS is an asynchronous protocol (it uses UDP), the optimal solution would involve integrating RADIUS access into the event loop, using the non-blocking FreeRADIUS client library calls to send requests to the RADIUS server and periodically polling for responses. Ideally, the RADIUS client socket could be integrated into the poll set.