[asterisk-users] Radius Based Accounting for Asterisk

[Nathan Anderson]

On Friday, April 26, 2013 11:38 PM, basteon wrote:

> On 3 February 2011 09:44, Nikhil <d.nikhil at cem-solutions.net> wrote:
> 
> > Hi everyone
> >  Any one used Radius based accounting for asterisk.Please give me
> > details.
> 
> hi,
> you still interesting in it?
> that I made long time ago.
> http://lists.digium.com/pipermail/asterisk-dev/2010-March/043096.html
> also I keep another patches and things and I need dedicated ftp for
> it. if you can give me such things I'll provide this patch to you.

I have to say, I'm confused.  Asterisk already supports RADIUS Accounting (for CDRs), and has for quite some time.  What it doesn't support is RADIUS Authentication.  I'd have to think that even if it did support RADIUS Auth, barring some kind of architectural overhaul, it would have to happen on a channel-driver-by-channel-driver basis.

I, for one, would love to see true RADIUS Auth show up in chan_sip at the very least.  As I understand it, there are a couple of obstacles inherent in the current architecture that makes this a not entirely simple problem to solve.

The first obstacle is that chan_sip currently needs to know each peer's secret, whereas if you are using a RADIUS server, the actual secret/password would never be known to Asterisk.  SIP uses HTTP-style digest authentication, which can be tunneled over RADIUS, but chan_sip would itself need to be rewritten to be "RADIUS-aware", so that rather than require/expect the secret for a peer to be statically set in sip.conf and then perform the digest auth exchange itself, it simply sends the request on to the RADIUS server.  There was an effort some time ago (https://issues.asterisk.org/jira/browse/ASTERISK-5278) to separate peer authentication into a separate module that would have a plug-in architecture which would allow you to "bolt-on" different kinds of authentication back-ends as needed (RADIUS, PAM, LDAP, etc.) for channel drivers that supported it, but development of it was put on-hold back in 2007 and, as far as I can tell, hasn't been picked up by anyone since.

Even if res_auth had been finished and was in a working state, the other obstacle that nobody ever really attempted to address with it (as far as I was able to tell, from reading through the bug) was that even though it solved the secret-must-be-known-by-Asterisk problem, you still had to statically define all of your SIP (or IAX2, or whatever) peers in the appropriate conf file.  You would merely add an option that told it to check the password/secret via RADIUS, or PAM, or what-have-you, for that peer instead of statically typing the plain-text secret in the conf file for that peer.  If you still have to define all of the peers themselves in sip.conf, then doesn't that essentially make the RADIUS "support" useless?  What I suspect most people who want to use RADIUS with Asterisk would *expect* from such support is the ability to use RADIUS as the authoritative source for all peer definitions, and not merely as a central password store.  That is, they want to be able to utilize all 3 of the three-As of RADIUS AAA: Authentication, Authorization, and Accounting.  res_auth would have only taken care of authentication, not authorization (peer attributes, permissions, and settings).

You *can* create "dynamic" peers in chan_sip and chan_iax2 by way of Asterisk's Realtime Architecture.  And so I could forsee someone cobbling together RADIUS support by resurrecting res_auth (for authentication), and then perhaps creating a Realtime module (for authorization) that consulted a RADIUS server instead of a SQL database or whatever.  But you'd have to use both in conjunction with each other for a fully-working system: the Realtime RADIUS module would have to add the appropriate option to each SIP (or IAX2) peer that would in turn cause chan_sip to consult the RADIUS server for that peer's password, instead of cacheing the password/secret locally.  And that just seems real kludgey to me (although it might be better than nothing!).

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com