Asterisk
  1. Asterisk
  2. ASTERISK-5278

[patch] SIP peer authentication on an external database (RADIUS - LDAP)

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: None
    • Labels:
      None
    • SVN Revision Number:
      54702
    • Mantis ID:
      5424
    • Regression:
      No

      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 :

      [username]
      type=friend
      context=from-sip-remote-clients
      fromdomain=inria.fr
      auth_type=pam
      host=dynamic

      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 :
      http://bugs.freeradius.org/show_bug.cgi?id=259

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

      Best regards, happy Astricon to those concerned!

      Philippe Sultan
      INRIA

      PS : Disclaimer sent on 2005-09-30

                • ADDITIONAL INFORMATION ******

      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/

      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 :

      [ldap]
      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

      1. auth.conf
        0.4 kB
      2. dictionary.cisco
        4 kB
      3. radius.patch
        10 kB
      4. radius-dictionary
        13 kB
      5. radius-v1.0a.patch
        22 kB
        Popov Leo
      6. res_auth-auth_secret.patch
        2 kB
      7. res_auth-radiuscfg.patch
        1 kB
      8. res_auth-update.2.patch
        13 kB

        Activity

        Hide
        phsultan added a comment -

        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).

        Show
        phsultan added a comment - 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).
        Hide
        phsultan added a comment -

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

        Show
        phsultan added a comment - Seth, I thought you might be interested in this update note.
        Hide
        Tilghman Lesher added a comment -

        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?

        Show
        Tilghman Lesher added a comment - 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?
        Hide
        Olle Johansson added a comment -

        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.

        Show
        Olle Johansson added a comment - 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.
        Hide
        muhammad hasan added a comment -

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

        thank you

        Show
        muhammad hasan added a comment - how can i use this patch? because i want to try sip peer auth based on this guide? thank you

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development