login | register
Wed 01 of Aug, 2007 [09:19 UTC]

voip-info.org

Navigation
Today's Deals
Recently Visited Pages
Search with Google
Search this site with Google. Results may not include recent changes.

Web www.voip-info.org
Last Changes
Shoutbox
  • Aykut, Wed 01 of Aug, 2007 [07:53 UTC]: Hi all, does anybody know about Thomson ST2030 SIP phone. I have upgraded it to latest version (1.56) but "Hold" and "Conf" features are not working after the upgrade ?? Do you know any solution or do you have Ver. 1.52 ?? Where can I find it?
  • Edward J Brown, Tue 31 of Jul, 2007 [23:33 UTC]: Has anybody experienced Choppy voice quality when using a Linksys SPA942 in an Asterisk Conference bridge? It works fine with my polycom and Cisco, but sucks with my Linksys.
  • www.astawerks.com, Fri 27 of Jul, 2007 [18:00 UTC]: does anyone use asterisk on top of clark connect? does it work good?
  • simon, Fri 27 of Jul, 2007 [14:16 UTC]: Hi All, Has anyone here managed to get the Cisco79x1 to successfully fail over to the backup proxy. I have 2 asterisk servers , handsets all register and function, except that backup proxy function doesn't work. Any working example would be very apprecia
  • Matthew Richmond, Thu 26 of Jul, 2007 [03:40 UTC]: using the page() application to page across our building...often the meetme conferences don't disconnect after the caller hangs up. Anyone else having this problem. (using Polycom phones)
  • Matthew Richmond, Wed 25 of Jul, 2007 [02:58 UTC]: thanks Nicholas Blasgen! I haven't worked with AGI before, but there's always a first! Thanks again!
  • Nicholas Blasgen, Tue 24 of Jul, 2007 [19:18 UTC]: Matthew Richmond, AGI will handle all that for you.
  • sam, Mon 23 of Jul, 2007 [16:39 UTC]: need help - certain voicemail extension will stop working and recording voicemail on asterisk - anyone know why and how to fix it? Thanks
  • john haji, Mon 23 of Jul, 2007 [14:55 UTC]: free calls to pakistan
  • bong, Sat 21 of Jul, 2007 [19:09 UTC]: hi good day to all can anyone help me how to configured the nortel sip to the signaling server and how to activate in mobile w/ sip compatible without mcs
Server Stats
  • Execution time: 0.42s
  • Memory usage: 2.20MB
  • Database queries: 33
  • GZIP: Disabled
  • Server load: 3.07

Asterisk IAX authentication

Asterisk IAX Authentication


This page attempts to document the process that Asterisk uses to authenticate incoming and outgoing IAX2 connections. To go directly to setup instructions, see instead "configuring IAX clients". Reference to "type=user" in the text below should be assumed to include "type=friend' as well, since a friend can act as a user. The same assumption holds for "type=peer" references below.

Incoming Connections

When Asterisk receives an incoming IAX connection, the initial call information can include a username (in the IAX2 USERNAME field) or not. In addition, the incoming connection has a source IP address that Asterisk can use for authentication as well.

If a username is supplied, Asterisk does the following:
  • Search iax.conf for a "type=user" entry with a section name (eg [username]) matching the supplied username; if no matching entry is found, refuse the connection.
  • If the found entry has allow and/or deny settings, compare the IP address of the caller to these lists. If the connection is not allowed, refuse the connection.
  • Perform the desired secret checking (plaintext, md5 or rsa); if it fails, refuse the connection.
  • Accept the connection and send the caller to the context specified in the "context" setting for this iax.conf entry.
If a username is not supplied, Asterisk does the following:
  • Search for a "type=user" entry in iax.conf with no secret specified and also allow and/or deny restrictions that do not restrict the caller from connecting. If such an entry is found, accept the connection, and use the name of the found iax.conf entry as the connecting username.
  • Search for a "type=user" entry in iax.conf with no secret specified and no allow and/or deny restrictions at all. If such an entry is found, accept the connection. and use the name of the found iax.conf entry as the connecting username.
  • Search for a "type=user" entry in iax.conf with a secret (or RSA key) specified and also allow and/or deny restrictions that do not restrict the caller from connecting. If such an entry is found, attempt to authenticate the caller using the specified secret or key, and if that passes, accept the connection, and use the name of the found iax.conf entry as the connecting username.
  • Search for a "type=user" entry in iax.conf with a secret (or RSA key) specified and no allow and/or deny restrictions at all. If such an entry is found, attempt to authenticate the caller using the specified secret or key, and if that passes, accept the connection, and use the name of the found iax.conf entry as the connecting username.
Suppose your iax.conf file has the following entries:

[guest]
type=user
context=guest

[iaxtel]
type=user
context=incoming
auth=rsa
inkeys=iaxtel

[iax-gateway]
type=friend
allow=192.168.0.1
context=incoming
host=192.168.0.1

[iax-friend]
type=user
secret=this_is_secret
auth=md5
context=incoming

If an incoming call has a specified username of:
  • guest
  • iaxtel
  • iax-gateway
  • iax-friend
then Asterisk will attempt to authenticate the connection using only the matching iax.conf entry. If any other username is specified, the connection will be refused.

If no username is specified at all, Asterisk will authenticate the connection as the guest user. However, if you do not have a guest (no secret) entry in your iax.conf file, the connecting user can specify the secret associated with any other iax.conf entry that is not IP address restricted, and connect as that user. In this case, if the connecting user happens to specify "this_is_secret" as their secret, they will be connected as the "iax-friend" user, without having actually supplied that username during the connection process. If you have a large number of non-IP-restricted iax.conf entries and no guest entry at all, this means that you have a large number of "guessable" secrets that anyone can use to connect to your system.

Using RSA keys as your secrets is one way to avoid this problem without creating a guest user (since they are not "guessable"), another method is using IP address restrictions on as many of your iax.conf entries as you can manage.

Outgoing Connections

Outgoing Asterisk connections can gather their authentication information from:
  • the IAX2 channel description passed to the Dial command (see Asterisk IAX channels)
  • a "type=peer" or "type=friend" entry in iax.conf
  • a combination of these two sources
Suppose your iax.conf file has the following entries:

[iaxtel-outbound]
type=peer
username=iaxtel_username
secret=iaxtel_secret
host=iaxtel.com

[iax-gateway]
type=friend
allow=192.168.0.1
context=incoming
host=192.168.0.1

Then:

 Dial(IAX2/iaxtel-outbound/1234)

would connect to host "iaxtel.com", specifying the iax.conf-supplied username and secret for authentication.

 Dial(IAX2/user2:secret2@iaxtel-outbound/1234)

would also connect to host "iaxtel.com", but would specify "user2" and "secret2", overriding the entries in iax.conf.

 Dial(IAX2/iaxtel.com/1234)

Again, connection would be made to host "iaxtel.com", but no username or secret would be specified, as none were included in the IAX2 channel description and "iaxtel.com" does not match the names of any iax.conf "type=peer" entries (even though it matches a hostname specified within one of those entries).

 Dial(IAX2/iax-gateway/5678)

would connect to host 192.168.0.1, specifying no username at all, and if the host requests a secret, no secret will be supplied. Presumably this type of entry would be used for connections between very well trusted hosts.

See Also:


Created by kpfleming, Last modification by jason@debian.org on Thu 21 of Jun, 2007 [02:31 UTC]

Comments

Comments Filter
Edit

allow=IP-Adress doesn't work

by Anonymous on Wednesday 15 of September, 2004 [14:52:26 UTC]
use deny / permit Mask instead.

Authentication not quite as described

by softins on Thursday 29 of July, 2004 [21:27:11 UTC]
I don't know whether this is intended behaviour or not, but I have found that if a username IS supplied by the connecting party, but the called machine has NO matching "username" section of type=user or type=friend, the connection will NOT be rejected immediately, contrary to what was stated above. Instead it will proceed as if NO username was supplied, and use any other section with a matching secret.

Please update this page with new information, just login and click on the "Edit" or "Add Comment" button above. Get a free login here: Register Thanks! - support@voip-info.org

Page Changes | Comments

Sponsored by:
Terms of Service Privacy Policy
© 2003-2007 Arte Marketing, Inc.

Powered by bitweaver