Summary:ASTERISK-05278: [patch] SIP peer authentication on an external database (RADIUS - LDAP)
Reporter:phsultan (phsultan)Labels:
Date Opened:2005-10-11 08:44:52Date Closed:2011-06-07 14:03:15
Versions:Frequency of
Environment:Attachments:( 0) auth.conf
( 1) dictionary.cisco
( 2) radius.patch
( 3) radius-dictionary
( 4) radius-v1.0a.patch
( 5) res_auth-auth_secret.patch
( 6) res_auth-radiuscfg.patch
( 7) res_auth-update.2.patch
Description:We have been working on integrating an existing authentication database to our Asterisk server, for a remote access telephony solution.

We focused on RADIUS and patched Asterisk to have it working. We are planning to have a backend LDAP server accessed through RADIUS for authentication in a near future.

The sip.conf file does not contain any secret (clear or hashed), and we added an attribute 'auth_type' that specifies the type of authentication, set to PAM in the following example :


We patched the chan_sip.c file, $Revision: 1.872$. We actually brought the RADIUS client functionnality for authentication (triggered on registration) using a PAM module : pam_radius. This is because we expect that other PAM authentication modules than pam_radius could be used for the same purpose.

The pam_radius module needed also some slight modifications in order to handle the digest authentication mechanism :

We would like to have some feedback about this, thank you in advance.

Best regards, happy Astricon to those concerned!

Philippe Sultan

PS : Disclaimer sent on 2005-09-30


Detailed information about how we set up external authentication on registration with Asterisk, RADIUS and LDAP, and more generally about the conflicts between digest auth and LDAP can be found here :


The branch with the latest code is located at:

Latest modification now allows AMI users to rely on res_auth for authentication.

-------- Configuration help ---------
The secret line in a configuration file is processed this way :
secret = <auth_proxy>:[auth-db:[password]]

examples :
secret = local:file:mypassword ; Authenticate on Asterisk, password in string
secret = radius: ; Proxy authentication to an external RADIUS server
secret = local:ldap: ; Authenticate on Asterisk, retrieve password from an LDAP server

In the latter case, the configuration information must be set in the /etc/asterisk/auth.conf file (attached). Example :

dbhost=ldapserver.example.com ; LDAP host(s)
dbbasedn=dc=inria,dc=fr ; Base DN
dbuser=uid=Manager,ou=people,dc=example,dc=com ; Bind DN
dbpass=password ; Bind password

user_name_attribute=login ; The LDAP login attribute
user_password_attribute=userPassword ; The LDAP password attribute
Comments:By: Olle Johansson (oej) 2005-10-11 22:16:21

We need a generic API for handling authentication from various external sources, otherwise we will end up with different implementations in different channels and apps. This needs to be integrated in the work with a future res_user_auth module.

This reminds me of pre-realtime, when one app supported Mysql, another Postgres etc.

Other than that, I like seeing new auth sources added. Let's continue this discussion after 1.2 release.

Greetings from the Astricon Code Zone!


By: phsultan (phsultan) 2005-10-21 14:58:46

Sorry Olle, couldn't wait for 1.2 release to continue on this topic :)

Yes, a generic API for authentication is necessary.
Two notes regarding this :
- PAM is actually made to handle different authentication against various authentication sources
- the SIP digest authentication scheme can be achieved by interfacing RADIUS entities, not directly through LDAP for example.

More generally, a simple attribute retrieval protocol such as LDAP is not designed to achieve directly SIP digest authentication, just because of the nonce handling needed in digest auth.

Kind regards,


By: phsultan (phsultan) 2005-11-24 03:16:24.000-0600

Patch updated, succesfully tested along with a CVS checkout dated 2005-11-23.
Makefile release : 1.231
chan-sip.c release : 1.917

As Olle mentioned, a res_user_auth module is more appropriate to handle this.


By: Olle Johansson (oej) 2005-11-24 03:40:13.000-0600

I am working on an Asterisk user management module. It will be interesting to test that together with this.

By: phsultan (phsultan) 2005-11-24 04:03:57.000-0600

Great, I'll be waiting for the testing release of this module then.

By: phsultan (phsultan) 2005-12-22 09:45:39.000-0600

Thinking of a generic API for user authentication, I have a few
comments regarding a possible RADIUS authentication for IAX users.

Authentication in IAX occurs in REGREQ - REGAUTH messages, and in
AUTHREQ - AUTHREP messages. The IAX-MD5 authentication relies on a
challenging procedure, so I tried to compare it to similar RADIUS
authentication procedures : CHAP and Digest.

But, currently I cannot figure out how to implement any of those authentication
methods as is for IAX peers.

-- [CHAP authentication]

Challenge result in MD5-IAX authentication is computed this way :
hash(concat(challenge, secret))

Challenge response in CHAP authentication is computed this way :
hash(concat(identifier, secret, challenge))

The 'identifier' field on CHAP has an incrementally changing value
(see 2.1 in RFC 1994). By using the IAX Outbound Sequence Number for
example, and reordering the challenge computation parameters in
MD5-IAX, one could authenticate IAX peers against a RADIUS server
using CHAP. Of course, a RADIUS client function integrated with
Asterisk would be necessary (perhaps in the generic user management
module Olle is working on).

-- [Digest Authentication]

The RADEXT working group has been working on a document that describes
how provide a RADIUS client functionnality to a SIP proxy, in
order to move the authentication process to an external RADIUS server

This draft is expected to become standard in a near future.

At least, the following RADIUS attributes must be sent to the server
(all values are taken from the SIP transaction) :

While this kind of authentication works fine with SIP peers, it is
difficult to adapt it to IAX peers, because of the protocol
itself. One solution might be to create new IEs in IAX, and map them
to RADIUS attributes.

By adding the realm, method, uri IEs in IAX, and mapping them to the
corresponding RADIUS attributes, one could authenticate IAX peers
against an external RADIUS server using digest authentication.
Regarding the remaining attributes, the following mapping might be
used :
Digest-Nonce <=> IE challenge
Digest-User-Name <=> IE Username
Digest-Response <=> IE MD5 Challenge result

Again, a RADIUS client function must be integrated in Asterisk in this
case too.

In case RADIUS would be considered as a valuable authentication
source, I wonder how it could be implemented as a module that would
serve both IAX and SIP peers.

Thank you for your comments, and for having read this quite lengthy note :)

By: Olle Johansson (oej) 2006-01-04 12:59:35.000-0600

Guess this is a large area, but needed. Apart from radius, do we have any input on other auth schemes, do they generally work the same way?

By: phsultan (phsultan) 2006-01-06 03:29:01.000-0600

Older AAA protocols such as TACACS(+) won't get any support for SIP authentication, and the RADEXT WG is working to add digest authentication to both RADIUS and Diameter.

I can't think of any other authentication protocol able to directly handle SIP digest authentication, and *none* to handle IAX authentication.

By: phsultan (phsultan) 2006-03-01 17:03:31.000-0600

I worked on Olle's ASTUM branch, and set up a resource module able to handle authentication.

Currently, the module takes a 'password' string (ex: 'secret=' in chan_sip) which is formed of a keyword sequence, thus following Olle's advice. For example, for a locally stored password :

The first keyword indicates the protocol used to proceed with user authentication, or to fetch a password from an external source :
- local : password in stored locally, at the end of the 'secret' string
- radius : authenticate the user through RADIUS
- ldap : use LDAP to retrieve the password from an external directory
- pam : authenticate the user through PAM

Currently, 'local' and 'radius' are available. The latter has been implemented in res_auth by linking the radiusclient-ng API (used in SER) to it. This API must be installed if we want to authenticate users throught RADIUS. It provides the RADIUS client functionnality to Asterisk, needed to talk to a RADIUS server.

This scheme can be applied to chan_sip (included in the provided patch), or to chan_iax, or even other channels.

Branch URL : http://svn.digium.com/svn/asterisk/team/oej/astum
Revision: 11502

File to add :
./astum/include/asterisk/auth.h (attached)
./astum/res/res_auth.c (attached)

Patch :
patch -p0 < asterisk-res_auth.0.1.patch

By: mario (asteriskstar) 2006-03-08 17:10:13.000-0600

Olle's ASTUM branch, and set up a resource module able to handle authentication.

1 secret=local:clear:mypassword
-----how to configure for Radius auth ?

2 will there be a updated version for IAX ?

By: phsultan (phsultan) 2006-03-25 11:35:06.000-0600

Example of a record for a SIP peer configured for RADIUS authentication :

I am working on a patch to chan_iax.c so that a similar scheme can be applied to the secret field in iax.conf.

However, the IAX protocol does not permit to authenticate a user with RADIUS the same way SIP does it (see the previous note about CHAP and DIGEST authentication), unless the user authenticates with the unsecure 'plaintext' method.

By: Olle Johansson (oej) 2006-03-27 16:36:51.000-0600

Opened branch "team/oej/res_auth"

Please test and make sure I've got everything in there.

By: phsultan (phsultan) 2006-03-28 09:48:08.000-0600

It looks like the 'res_auth/res/Makefile' has not been patched to compile res_auth properly. Sent 'res_auth-res_makefile.0.1.patch' to solve this.

Also successfully tested the RADIUS authentication for SIP users upon registration.

By: Serge Vecher (serge-v) 2006-05-25 21:35:31

philip: time for an update here?

By: phsultan (phsultan) 2006-05-29 02:21:48

True. It would be nice to have res_auth module rely on the autoconf RADIUS API detection result. I am also waiting for Olle's input on a few related points.

Please grant me a couple of weeks to get this moving, as I am quite busy with my daily job.

By: phsultan (phsultan) 2006-06-05 15:21:15

Update to the res_auth branch :
- autotools detection for both the radiusclient-ng and ldap (openldap) APIs
- ldap password retrieval
- application to chan_sip

The secret line in chan_sip.conf is processed this way :
secret = <auth_proxy>:[auth-db:[password]]

examples :
secret = local:file:mypassword   ; Authenticate on Asterisk, password in string
secret = radius:                 ; Proxy authentication to an external RADIUS server
secret = local:ldap:             ; Authenticate on Asterisk, retrieve password from an LDAP server

In the latter case, the configuration information must be set in the /etc/asterisk/auth.conf file (attached). Example :

dbhost=ldapserver.example.com           ; LDAP host(s)
dbbasedn=dc=inria,dc=fr                 ; Base DN
dbuser=uid=Manager,ou=people,dc=example,dc=com    ; Bind DN
dbpass=password                         ; Bind password

user_name_attribute=login               ; The LDAP login attribute
user_password_attribute=userPassword    ; The LDAP password attribute

We certainly need to process the retrieved LDAP password value to handle different storage types. Currently, a clear text string is expected by the module upon pullout from an LDAP server.

Maybe we also need another separator than ":"

The res_auth-autoconf_ldap.0.1.patch must be applied to the res_auth branch to have this working. 'bootstrap.sh' must be called before 'configure' as the 'configure.ac' file has been changed.

All of the previous files can be deleted, that is :
- asterisk-res_auth.0.1.patch
- auth.h
- res_auth.c
- res_auth-res_makefile.0.1.patch

By: phsultan (phsultan) 2006-06-28 09:36:15

New patch version in order to follow the automatic updates from the trunk.

By: Serge Vecher (serge-v) 2006-06-28 10:02:50

is this still considered "experimental" or there are successful deployments of this in the field?

Also, ok to delete res_auth-autoconf_ldap.0.1.patch?

By: phsultan (phsultan) 2006-06-28 10:58:00

Serge : ok to delete res_auth-autoconf_ldap.0.1.patch

By: phsultan (phsultan) 2006-10-19 09:54:26

An update to the res_auth branch, that modifies the following files :
- build_tools/menuselect-deps.in
- channels/chan_sip.c
- configure.ac
- include/asterisk/auth.h
- makeopts.in
- res/res_auth.c

SVN version : 45677

Since configure.ac has been modified to add OpenLDAP checking, the following commands must be run by a user who would like to compile this branch :
- bootstrap.sh
- configure
- make
- make install

Note : the draft that describes how RADIUS can fit with SIP digest authentication, and that has been used in this branch, now became RFC 4590 : http://www.ietf.org/rfc/rfc4590.txt. Compliance with this document will be achieved in a next update to res_auth.

Possible improvements and limitations :
- any possibility to integrate res_auth with AMI, chan_jingle, chan_gtalk, res_jabber?
- automatically process HA1 strings for SIP authentication (maybe prefixed with a "{MD5}" string)

The res_auth-autoconf_ldap.0.2.patch can be deleted.


By: Olle Johansson (oej) 2006-10-20 02:02:50

Updated branch with latest patch. Please test.

By: Pavel Shramov (psha) 2007-01-02 05:10:46.000-0600

Compilation of svn current revision (49132) without openldap support fails on res/res_auth.c
Patch to fix this is attached (res_auth-ldap-compile-fix.patch)

By: phsultan (phsultan) 2007-01-03 04:09:35.000-0600

Thanks for fixing this psha. Do you have any feedback regarding the usage of the module, and improvements you'd like to see implemented?

By: Abylai Ospan (aospan) 2007-01-04 10:30:00.000-0600

ast_copy_string is corrupting digest string because \0 added. For example:
original digest received from user is:

but following digest is sent to radius server:

Radius (UTM5 radius) rejects this Digest-MD5 auth.
Small dummy fix is uploaded (res_auth_digest-fix.patch). I'v changed ast_copy_string to strncpy. May be ast_copy_string need to modify.

By: Pavel Shramov (psha) 2007-01-05 15:54:45.000-0600

First it would be nice to have configurable path to radiusclient config. If it's needed I can attach patch (based on cdr/cdr_radius code).
Next. Bug reported by aospan may be fixed by increasing size of digest_response field of digest_params struct from 32 to 33 bytes.

More complicated issue is that current implementation lack pure dynamic users.
If you have one in radius you have to add "[username]\nsecret=radius:" in configuration file/database or enable auto-registration. During auto-registration user with empty secret (secret = '\0') is created. So external (radius) authorization is not performed. Maybe [auto-defaults] section will solve this problem?

By: Pavel Shramov (psha) 2007-01-09 02:37:06.000-0600

I've uploaded smaller fix for digest_response bug reported by aospan.
Also patch for tunable radiusclient config file (res_auth-radiuscfg.patch)
And one adding secret= variable in [general] section of sip.conf for auto-registered users. No sanity check is performed but maybe restrict this field to radius: ldap: pam: ...?

By: phsultan (phsultan) 2007-01-12 08:40:26.000-0600

> I've uploaded smaller fix for digest_response bug reported by aospan.

I am not sure we should extend the digest size. It could be confusing not to  keep the exact size of an MD5 string result.

> Also patch for tunable radiusclient config file (res_auth-radiuscfg.patch)
> And one adding secret= variable in [general] section of sip.conf for auto-
> registered users. No sanity check is performed but maybe restrict this field > to radius: ldap: pam: ...?

I fully agree with that, can you restrict this field to the proposed values?

By: Pavel Shramov (psha) 2007-01-14 04:58:13.000-0600

> I am not sure we should extend the digest size. It could be confusing not to keep the exact size of an MD5 string result.

First it's string and if we use string calls to manipulate with it we have to leave space to store trailing null byte.
In code sending it to radius there is explicit size specification. It's easier to make mistakes in copying then in external input/output (in my opinion).

Patch for restricting secret variable to "methon:" will be ready in several days.

By: John Guthrie (guthrie) 2007-02-14 14:07:27.000-0600

In the summary, it indicates that this work is being done in a branch.  Just to confirm, would that be the 1.4 branch?  If I wanted to test these features out, would I need to grab the latest version of that branch, and then apply the patches that are listed above?


By: Serge Vecher (serge-v) 2007-02-14 14:29:25.000-0600

no, the code is in developer's branch (See "Addition Information" field), and  like all new features, development branches are not based on release branches, but trunk.

By: John Guthrie (guthrie) 2007-02-15 00:04:28.000-0600

I found the correct location in the svn tree, and I grabbed that.  I then applied the last five patches that were listed above.  (The five that are newer than Jan. 1, 2007.)  When I ran the bootstrap.sh script to regenerate the configure script, I got the following:

Generating the configure script ...
configure.ac:31: error: possibly undefined macro: AC_USE_SYSTEM_EXTENSIONS
     If this token and others are legitimate, please use m4_pattern_allow.
     See the Autoconf documentation.
configure:3799: error: possibly undefined macro: _AC_PATH_PROG_FEATURE_CHECK
configure:3800: error: possibly undefined macro: _AC_FEATURE_CHECK_LENGTH

However, it looks like the configure script was regenerated.  When I tried running the configure script anyway, it terminated with the following error:

checking for a sed that does not truncate output... ./configure: line 3799: syntax error near unexpected token `SED,'
./configure: line 3799: `     _AC_PATH_PROG_FEATURE_CHECK(SED, sed gsed,'

(I suppose this isn't shocking.  I was warned about that macro not being defined.  Oh well.)

I am running this on an FC6 system with autoconf 2.59 and automake 1.9.6.  (2.59-12 and 1.9.6-2.1, respectively, to be more precise.)  Are those macros particular to autoconf 2.60 and above?

By: John Guthrie (guthrie) 2007-02-15 18:27:51.000-0600

I upgraded my autoconf and m4.  That fixed the problem that I just mentioned.  I just checked out the latest version of res_auth code from oej.  (I used

svn co http://svn.digium.com/svn/asterisk/team/oej/res_auth asterisk

to do the check out.)  I applied the last five patches above, and the configure script worked just fine.  However, the compilation stopped with the following error:

  [CC] codec_zap.c -> codec_zap.o
codec_zap.c: In function 'zap_destroy':
codec_zap.c:222: error: 'ZT_TCOP_RELEASE' undeclared (first use in this function)
codec_zap.c:222: error: (Each undeclared identifier is reported only once
codec_zap.c:222: error: for each function it appears in.)
codec_zap.c: In function 'find_transcoders':
codec_zap.c:519: error: 'struct zt_transcode_info' has no member named 'numchannels'

I have grepped through every file, and the only time that this symbol ZT_TCOP_RELEASE is mentioned is in the file codec_zap.c.  Is this a recent change?  (The 'struct zt_transcode_info' error has the same problem.  It has one definition on line 503 of codecs/codec_zap.c:

struct zt_transcode_info info = { 0, };

nothing about numchannels.)

By: phsultan (phsultan) 2007-02-16 07:26:29.000-0600

guthrie: compilation works fine for me, but Zaptel is not included in my system. You may want to disable codec_zap in menuselect?

make menuselect => select 4. (Codec Translator) => unmark 11. (codec_zap)

Thanks for your feedback!

By: John Guthrie (guthrie) 2007-02-20 17:45:11.000-0600

Hello all.  I'm feeling a little boneheaded right now.  I've been a bit short on sleep recently, so it took me a little while to figure out that if I'm using asterisk from subversion, then maybe I need to use zaptel libraries from subversion as well.  ("Duh!")  Anyway, once I got that figured out, and I upgraded my autoconf (which required an upgrade to m4, BTW.)  I was able to compile just fine.  The program runs without any major errors.  (I have yet to see any SEGVs or the like.)

A couple of comments:  the default configuration of the radiusclient-ng library is not very friendly to programs not running as root.  So if you use the -U flag you may need to point asterisk at its own radiusclient config file that has its own server file.  Whatever user asterisk is running as will need to be able to read this file.  (This file is kept separate from the main file because it contains radius client secrets.)  I had a similar problem with the seqfile setting in the radiusclient.conf file.  This is just something that people will need to look out for.

However on a more serious note, I currently have a client that is trying to authenticate against the RADIUS server, and the RADIUS server is complaining about the User-Password attribute not being provided.  Hence, it is failing to authenticate.  It seems as though asterisk is not providing a Digest-HA1 attribute either.  I have verified this with a packet sniffer.  The only RADIUS config that I have done is I have pointed asterisk at the appropriate radiusclient-ng config file, and I have set the secret for the test user to "radius:" in the sip.conf file.

By: John Guthrie (guthrie) 2007-02-20 21:07:32.000-0600

Looking at the code in channels/chan_sip.c, between lines 8345 and 8394, you can see the RADIUS attributes get built up.  But there is nothing about computing the Digest-HA1 attribute.  And then then request gets sent off at line 8396.  The RADIUS server then gives out the complaint:

Auth: rlm_digest: Configuration item "User-Password" or Digest-HA1 is required for authentication.

(This is using SVN 54702 and the patches above.)

By: phsultan (phsultan) 2007-02-21 03:27:35.000-0600

Hi guthrie!

Actually, the error message displayed by FreeRADIUS refers to its configuration file not containing either a "User-Password" or "Digest-HA1" attribute for the user you want to authenticate. The client-side computed value is carried over the network in a "Digest-Response" RADIUS attribute.

Please check your FreeRADIUS "users" file, hereafter are sample entries for user "bob". Choose either form, the latter stores an encrypted form of the password (MD5(username:realm:password))
bob Cleartext-Password := "zanzibar"
bob Digest-HA1 := "12af60467a33e8518da5c68bbff12b11"

I'm running a CVS HEAD revision of FreeRADIUS, where "Cleartext-Password" replaced "User-Password".

Also, a description is available here (based on the old fashioned "User-Password" attribute) : http://wiki.freeradius.org/Digest

By: John Guthrie (guthrie) 2007-02-21 10:18:21.000-0600


What you told me worked great!  Thank you very much.  (I was close.  I had
"Digest-HA1 == blah", not "Digest-HA1 := blah".)  I was wondering, would there be some way to code into Asterisk the option of using a plain User-Password attribute?  The reason that I ask is that I have my RADIUS server configured to talk to a Kerberos server, not an LDAP server.  Alternatively, is it possible to integrate the SIP authentication with a RADIUS server that is acting as a Kerberos client?  Are there any SIP clients that can do plain password authen?

By: cm (cm) 2007-04-03 04:21:41

When is it supposed to include the res_auth code into the asterisk primary branch?

By: Rogelio J. Baucells (rjbaucells) 2007-04-03 19:40:39


What is the status of the authentication module?

I contributed a LDAP authentication module to SER some time ago and followed two approaches:
- storing the password in a clear form in the LDAP database
- storing the HA1(username:realm:password)
The module will use one of the approaches based on the configuration file and apply the required steps to authenticate the incoming message.
A similar solution can be implemented to authenticate IAX peers (CHAP).

I will look at the current SVN code.


By: phsultan (phsultan) 2007-04-27 08:50:37

Update to the res_auth branch (added support for AMI) - file res_auth-update.2.patch :
- allow users in manager.conf to be authenticated using res_auth. At that time, supported external authentication resources are LDAP and RADIUS
- increased buffer size for digest_response, as suggested by aospan and psha
- fixed a compilation problem as per note ASTERISK-5558070 (thanks to Pavel Shramov - psha)
- got rid of mutexes for RADIUS (sockets are handled by the system)
- added functions to authenticate directly through LDAP (simple bind) and RADIUS (simple authentication).

I had to 'embed' the res_auth module in Asterisk, because of the reference resolution that occurs when linking 'manager.o' to 'asterisk'.

Pavel, thanks for your help. We need you to send a disclaimer so that we can move on and include your patches regarding the global secret configuration as well as the radius configuration file path. I think your previous fixes were simple enough not to require a disclaimer from yours.

Files that can be deleted :
- res_auth-autoconf_ldap.0.2.patch
- res_auth-update.1.patch
- res_auth-ldap-compile-fix.patch
- res_auth_digest-fix.patch
- res_auth-digest-fix-2.patch

Serge, could you please include the examples from note ASTERISK-4609316 in the additionnal information section of the bug report, and mention somewhere that res_auth applies to SIP and AMI users as well :) ? I don't have the necessary privileges to do it myself.

Have a nice week end,


By: phsultan (phsultan) 2007-04-27 08:56:42

rjbaucells: the module is experimental. It would be great to have the password attribute retrieved from LDAP processed differently if encrypted.

I would suggest the following :
- fetch the password as a simple LDAP attribute, just the way we currently do
- if the retrived string starts with {MD5}, proceed considering a HA1 value
- if not, proceed considering an unencrypted password value

What do you think?

By: Pavel Shramov (psha) 2007-04-27 13:20:27

If You need some formal letter from me or smth in the code - tell me how can I do it :)
I'm not familar with this side of coding :)
If You'll send me instruction - i'll send You what you want :)
shramov 'at' mexmat 'dot' net

By: phsultan (phsultan) 2007-04-27 15:18:04

Hi Pavel,

check the bottom of bug tracker welcoming page : http://bugs.digium.com/main_page.php

A disclaimer is needed in order to include your code in Asterisk. Please file it to Digium, not me :)

By: Popov Leo (nabam) 2007-06-08 08:55:03

Patch for full support of radius accounting and autorization based on last res_aut_new. Added variables fo extension.conf - ${MAX_DIALOG_TIME} and ${BALANCE} with information from radius server.

Required dictionary.sip and dictionary.cisco

And i not found attribute
ATTRIBUTE       Acct-Interim-Interval   85      integer
so i'm add it to base dictionary.

By: Serg V (__serg__) 2007-06-14 09:49:15


Where locate res_auth_new?
Can you write small howto about get and patch asterisk+res_auth? (or post link to latest svn branch with res_auth and which patches need)

By: Popov Leo (nabam) 2007-06-14 18:19:07


Detailed information about how we set up external authentication on registration with Asterisk, RADIUS and LDAP, and more generally about the conflicts between digest auth and LDAP can be found here :

http://www-rocq.inria.fr/who/Philippe.Sultan/Asterisk/asterisk_sip_external_authentication.html [^]

The branch with the latest code is located at:
http://svn.digium.com/view/asterisk/team/oej/res_auth/ [^]

By: phsultan (phsultan) 2007-06-15 05:54:52

Nabam : it looks like your modifications are out of the scope of this bug report, which deals with authentication only.

Your changes imply interesting though heavy architectural changes to Asterisk (RADIUS CDR start record) that need to be discussed before for example on the -dev mailing list or IRC.

Also, I don't think we should include new dictionary files, but rather modify the existing dictionary.digium if needed. One question : why exactly do you need dictionary.cisco here?

By: Popov Leo (nabam) 2007-06-15 07:22:51

I'm not developer so i don't know full procedures of inserting modifications in the asterisk source code, so I will be very grateful if you help me.

I used cisco dictionary because I needed to implement functions to work with radius server integrated to our billing system UTM which supports only cisco products.

By: Popov Leo (nabam) 2007-07-25 11:08:19

I wroute patch based on this res_auth, which fully compatible with NetUP UTM billing system. I still uses cisco dictionary for radiusclient-ng. Patch is compatible with asterisk 1.4.9.

1. I remove LDAP section, because of some troubles with build it, sorry
2. modification in cdr_radius - now it sends start request at the end of call before end request with correct time in h323-setup-time (cisco dictionary) field.
3. resolved bug with '\0' at the end of digest field in radius message.
4. new sip.conf parameters "external_peers" (yes/no like autocreatepeers) and "external_method" (now supports only "radius" value)
5. variables ${MAX_DIALOG_TIME} and ${BALANCE} from radius response from server after auth (h323-credit-time and h323-credit-amount from cisco dictionary)

files: radius-v1.0a.patch, radius-dictionary

By: seth vidal (skvidal) 2007-08-02 01:21:47

I've been trying to figure out if this set of patches is generic enough to support general pam authentication. Something like what I've described here:


the gist of it is: if the user has a system account (auth'd by pam) then they also have an asterisk account for users.conf purposes.


By: Olivier Krief (okrief) 2007-08-02 03:33:19

It seems that several enhancements to original patch scope are added now and then.

I'm wondering if we should better focus on testing original patch, have it committed to trunk ASAP and keep further improvements to next release cycle.

This patch has already a long history and we need SIP authentication on an external database now.

How could we add IAX authentication or PAM or whatever if don't start now to gather field experience.

So, does the original patch work for you ?

By: phsultan (phsultan) 2007-08-22 03:33:15

skvidal : the initial patch used PAM to make Asterisk a RADIUS client that would authenticate users from a RADIUS server. This approach has been abandonned, and the RADIUS client Asterisk relies on is the radiusclient-ng API (also used by Asterisk for handling RADIUS CDRs).

Now, an LDAP server has been added to the authentication resources Asterisk can use. Asterisk uses the openldap API to be able to authenticate users.

I'll have to update the 'description' section of this bug report, but the 'additional information' is up to date. I'll have also to update the branch that contains the code :)

A general comment on authenticating SIP users, following your post on the forum : keep in mind that SIP uses a challenge/response mechanism for user authentication, so that actual passwords never travel over the network. While this mechanism can be reliably used to exchange credentials, it prevents from using authentication database that would store passwords in an unreversible encrypted form (SHA or MD5 for example).

Two alternatives for storing passwords for SIP accounts : clear text, or HA1 string.

XMPP (Jabber) for example, does have this problem, as it comes along with a flexible authentication mechanism and can be secured with TLS (SIP over UDP cannot be secured with TLS).

By: phsultan (phsultan) 2007-08-22 03:36:58

Seth, I thought you might be interested in this update note.

By: Tilghman Lesher (tilghman) 2007-11-06 19:00:10.000-0600

What is the status of this issue?  I'm noticing that the res_auth branch is about 6 months out of date, and the most recent patch attached to this bug is against 1.4, not against trunk.  Are there additional issues that still need attention?

By: Olle Johansson (oej) 2007-11-26 00:44:11.000-0600

philippe and I decided to suspend this patch while waiting for assignment of more than 24 hours per day. Neither of us has worked with the code for a while.

If anyone is interested in working on this, feel free to contact us.

By: muhammad hasan (hasan) 2014-09-04 04:56:38.200-0500

how can i use this patch? because i want to try sip peer auth based on this guide?

thank you