Authorization, Authentication and Accounting 
for
SIP express router

Introduction:
The purpose of this project was to port the existing SER AAA infrastructure  to RADIUS based solution. The decision to proceed with RADIUS instead of the IETF recommended AAA architecture, DIAMETER, was based on practical considerations such as the lack of an open-source implementation of DIAMETER server and the , still, infantile stage of the  proposal.

Radius Tools:
For the implementation, it was decided, after careful deliberation,  to proceed with two basic tools for the completion of the project. First, the RADIUS server implementation chosen for the job was Freeradius (http://www.freeradius.org/) which seemed to be one of the most active and promising open-source solutions. Second, a library was chosen in order to facilitate deployment. For this purpose the radiusclient library was employed. Radiusclient is one of two basic choices freely available for RADIUS deployment, the other being libradius. The choice between the two libraries was relatively arbitrary.

Authorization:

HTTP/SIP           RADIUS

    +-----+    (1)    +-----+           +-----+
    |     |==========>|     |           |     |
    |     |    (2)    |     |           |     |
    |     |<==========|     |           |     |
    |     |    (3)    |     |           |     |
    |     |==========>|     |           |     |
    |  A  |           |  B  |    (4)    |  C  |
    |     |           |     |---------->|     |
    |     |           |     |    (5)    |     |
    |     |           |     |<----------|     |
    |     |    (6)    |     |           |     |
    |     |<==========|     |           |     |
    +-----+           +-----+           +-----+

    ====> HTTP/SIP
    ----> RADIUS

The roles played by the entities in this scenario are as  follows:

A: HTTP client / SIP UA

B:  {HTTP  server / HTTP proxy server / SIP proxy server / SIP UAS} acting also as a RADIUS NAS

   C: RADIUS server

The relevant order of messages sent in  this  scenario  is  as follows:

 A  sends  B  an  HTTP/SIP request without authorization header (step 1). B challenges A sending an HTTP/SIP  "(Proxy)  Authorization  required"  response  containing  a locally generated nonce (step 2). A sends B an HTTP/SIP request with  authorization  header  (step 3). B sends C a RADIUS Access-Request with attributes described in this document (step 4). C responds  to B with a RADIUS Access-Accept/Access-Reject response (step 5). If credentials were accepted B receives an  Access-Accept  response and the message sent from A is considered authentic. If B receives an Access-Reject response, however, B then responds to  A  with  a "(Proxy) Authorization required" response (step 6).

Having chosen a RADIUS implementation for our AAA architecture transcribed into having to further the protocol to meet some the authentication requirements/suggestions currently deployed by SIP. With Basic authentication removed from the SIP RFC and that fact that SER already employed a Digest authentication scheme, it was decided to extend the freeradius implementation to support Digest. The extension was required due to an incompatibility between the mapping of the hashing algorithms used in Digest Authentication and RADIUS.

For Digest Authentication in SIP using RADIUS, two Internet Drafts were examined. The first proposal by Byerly and Williams, which was based on CHAP, was rejected due to its requirement for making changes to the SIP stack. The second and chosen proposal, was provided by Sterman. This proposal required minimal changes to the server and allowed the storing of the first part of the digest algorithm to be stored instead of a plain-text password [STERMAN]. 


Accounting:
The accounting information generated by SIP are communicated to the AAA server from the SIP server using RADIUS. In our case, SER becomes the client and freeradius the server. Specific SIP events that mark the beginning  and end of calls are transported to the server in accounting request packets. The server, if it successfully received and processed the request, replies with an accounting response.

The approach taken for our implementation was based upon the Internet Draft proposed by Schulzrinne. Mappings were created between existing RADIUS attributes and some new mappings were created specifically for SIP purposes. All the mandated fields were implemented with some open for future enhancements, namely, the Acct-Session-Time and Acct-Terminate-Cause.
Authorization:
The only authorization field that was currently required by SER could be served by a group assignments to users, indicating their calling capabilities. Further enhancements would include connecting to a MYSQL database through RADIUS to determine more granular user capabilities.

Configuration:
 
Radiusclient 0.3.2: 
Compile and install the radiusclient library. 
	./configure
	make
	make install (as root)

The radiusclient.conf file included in the sip_router/etc/  directory contains all the necessary pointer needed. Currently, some files need to be edited to point to the radiusclient.conf. These are indexed by the CONFIG_FILE define in both radius_acc and radius_auth modules. Furthermore, because the radiusclient.conf does not support relative directories, the pointers to the 'servers' and 'sip_dictionary' files have to be manually edited (in the sip_router/etc/ directory).

Finally, if the sip_router gives compile errors of not being able to link the hared object file radiusclient, run ldconfig. If that doesn't work, make sure that ldconfig.conf points to /usr/local/lib.

If there should be an upgrade to the radiusclient library, the main files that need to be changed are the ones containing the SIP defines.

FreeRadius 0.7:
Compile and install the latest FreeRadius version.
	./configure
	Edit the Make.inc file to include rlm_digest in the modules list
	make 
	make install (as root)

Copy the dictionary definitions (if not included in the distribution, meaning the one created at Fokus)

It is recommended that in the deployment phase, the radius daemon is run with the -X switch to allow for maximum debugging information. 
/usr/local/sbin/radiusd -X

The general configuration information for the freeradius server is located in the /usr/local/etc/raddb/ directory. The users directory found there includes the directory where user information is stored for use with the radius_auth module. 

An example user listing is the following.
steltest        Auth-Type := Digest,
	User-Password == "test", 
	Digest-Hash-A1 := "5fdf1606fca4de3d94ee69b887b454f4"
	 Reply-Message = "local"

Auth-Type is used to indicate that authentication is going to be performed by the Digest module. The User-Password parameter is optional and is only used to compute the Digest if the Digest-Hash-A1 parameter is missing. The Digest-Hash-A1 parameter should be used whenever possible since to 'hides' the plain text password entry for the user thus increasing system security. The  Digest-Hash-A1 is a computation of the user-name, realm and password which tends to remain static within a system. A helper utility which can be found in sip_router/utils/gen_ha1, can be used to generate this parameter. The Reply-Message is a current work-around for displaying the user's group designation. Further enhancements can be implemented by attaching directly to SER's  mySQL database.

































References:
SIP: Session Initiation Protocol			
	RFC 2543bis

Radius Extension for Digest Authentication  		
	draft-sterman-aaa-sip-00.txt

Digest Authentication in SIP using RADIUS
	draft-sterman-sip-radius-00.txt

Radius accounting for SIP servers
	draft-schulzrinne-sipping-radius-accounting-00.txt

SIP-AAA requirements 
	draft-loughney-sip-aaa-req-00.txt

AAA Requirements for IP Telephony/Multimedia
	draft-calhoun-sip-aaa-reqs-04.txt

Remote Authentication Dial In User Service (RADIUS)
	RFC 2138

Links:
http://www.freeradius.org/
http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=libradius
http://www.cs.columbia.edu/SIP
http://www.rad.com/networks/2000/radius/home.htm





