asterisk users - Apr 2013 - Radius Based Accounting for Asterisk

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.

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.
>
> Thanks
> Nikhil
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

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