Add Templating to iax.conf To Better Support Multiple Authenticated Clients

[ve7fet]

This enhancement fixes the issue of iaxRpt clients not being able to connect by adding the requirecalltoken = no option to the [iaxrpt] context in /etc/asterisk/iax.conf.

This enhancements implements templating for additional users to be easily added, without cluttering up iax.conf by having to copy/paste the same code block each time you want to add a new individual user (such as net control operators, each with their own callerid and account credentials).

Users are stored in /etc/asterisk/pc-clients.conf (for iaxRpt clients), and /etc/asterisk/an-clients.conf for Android (ie DVSwitch Mobile or Zoiper) clients. They CAN be moved in to a folder such as /etc/asterisk/custom/ by changing the include directive, such as #tryinclude custom/pc-clients.conf. Making sure, of course, that said folder has the proper ownership and permissions (asterisk:asterisk).

Adding new clients just requires duplicating the user authentication contexts, and adjusting account name (context), secret, and callerid, as required.

[InterLinked1]

I am against setting requirecalltoken=no without any other caveats. This is poor security advice and opens up systems to known vulnerabilities.

If you want to ensure that compatibility, I would restrict the number of non-validated calls using the approach for C*NET calls, here: https://github.com/InterLinked1/phreaknet-boilerplate/blob/master/iax.conf

[ve7fet]

Indeed, there is a security risk. However, if we're going to advertise/support its use, https://wiki.allstarlink.org/wiki/Setup/Download_IAXRpt , then iax.conf needs to have the requirecalltoken=no option set to allow it to work.

Otherwise, you end up with the threads on the discussion forum like there are now, "Why can't iaxRpt connect to ASL3".

Adding in a maxcallnumbers_nonvalidated = 64 (or other reasonable limit) wouldn't hurt.

The other option would be to try and track down the source from Xeletec, and try and update it (I think that's more unlikely).

[InterLinked1]

Indeed, there is a security risk. However, if we're going to advertise/support its use, https://wiki.allstarlink.org/wiki/Setup/Download_IAXRpt , then iax.conf needs to have the requirecalltoken=no option set to allow it to work.

Otherwise, you end up with the threads on the discussion forum like there are now, "Why can't iaxRpt connect to ASL3".

Adding in a maxcallnumbers_nonvalidated = 64 (or other reasonable limit) wouldn't hurt.

The other option would be to try and track down the source from Xeletec, and try and update it (I think that's more unlikely).

Using maxcallnumbers_nonvalidated is a fair compromise here (with a suitable number)

[ve7fet]

Committed maxcallnumbers_nonvalidated with comments into iax.conf in the PR.

More background on the potential DoS issue: http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/Security_id36001692.html

[Allan-N]

I'm not wild about the "an-clients" and "pc-clients" (and "an"/"pc") naming conventions mostly because I like to steer away from saying "this only applies to Android" or "this only applies to "PC"s. Maybe "iaxrpt-users" and "iaxclient-users"?

I'm also not wild about needing to have clients authenticate with usernames like <callsign>-an. Why not just <callsign> ?

The other comment I will make is that I've got some asl3-menu changes that will be adding files to [/etc/asterisk/]custom/rpt/*.conf, custom/simpleusb/*.conf, custom/usbradio/*.conf, etc. You might want to think about using the same convention (e.g. custom/iax/*.conf).

[ve7fet]

Changing the names of the credentials files to make them more agnostic isn't a big deal, I was just using the convention I've used on my systems. Same with moving them into /etc/asterisk/custom/iax/..., that's fine too... I'll have to leave the actual install script modifications to accommodate that to the experts... I haven't dug deep enough to see how that all works (and don't want to break anything).

The username authentication is a problem though if using just a callsign. The problem being if a user has an iaxRpt client and a DSVM client. You need to distinguish between the two accounts (clients), so that when the client tries to auth to Asterisk, the correct iax context and then extension is used.

If you have a client in each user file with the same callsign (account), then Asterisk doesn't necessarily pick the correct context/extension (tested).

Perhaps a -p for pc clients (iaxRpt) and -m for mobile clients?

[Allan-N]

The username authentication is a problem though if using just a callsign. The problem being if a user has an iaxRpt client and a DSVM client. You need to distinguish between the two accounts (clients), so that when the client tries to auth to Asterisk, the correct iax context and then extension is used.

If you have a client in each user file with the same callsign (account), then Asterisk doesn't necessarily pick the correct context/extension (tested).

Sure. But, this is only an issue when one wants to configure two clients using the same name. Could the documentation "suggest" that one use their callsign and include a caveat that if you are setting up multiple clients that then account names need to be unique. Here, you can even suggest using names like "yourcall-DVSM".

[ve7fet]

Sure, reverted to just plain callsigns for the suggested context name, and added some documentation around unique context naming for multiple clients.

[Allan-N]

All looks reasonable

[mkmer]

LGTM

[okcrum]

Is this complete, then, but for the change request? What happened to @ve7fet ?

[ve7fet]

Is this complete, then, but for the change request? What happened to @ve7fet ?

It should be able to be merged. I believe everything was resolved that was outstanding.

A compromise was reached to use maxcallnumbers_nonvalidated to store count

[Allan-N]

Q? the iaxrpt-users.conf and iaxclient-users.conf files are currently in the "rpt" directory (that will land in /etc/asterisk). Did we want to move them down into "rpt/custom/iax" so that they will be picked up by the #tryinclude ?

Also, I ran into some issues with templating the gps.conf file (#622). Are configurations without the #tryinclude file (or a filled out file) supposed to work if someone just modifies the template (but leaves it as a template) ?

[ve7fet]

Q? the iaxrpt-users.conf and iaxclient-users.conf files are currently in the "rpt" directory (that will land in /etc/asterisk). Did we want to move them down into "rpt/custom/iax" so that they will be picked up by the #tryinclude ?

Also, I ran into some issues with templating the gps.conf file (#622). Are configurations without the #tryinclude file (or a filled out file) supposed to work if someone just modifies the template (but leaves it as a template) ?

Scrolling back up to Mar 26 comments, the intent is to put those .conf files in /etc/asterisk/custom... exactly where would be up to your discretion, but /etc/asterisk/custom/iax would seem like a reasonable place.

I did some testing with iax.conf on a current distribution.

If I add the bang to template the instance: [iaxrpt]!, I can connect fine with the random generated password. With or without the #tryinclude... line didn't make any difference.

If I comment out the randomly generated secret (since it should be put in the client config), iaxRPT will connect as an "unauthenticated" call (versus an "authenticated" call when a valid secret is used).

With the #tryinclude and a valid .conf file with an iaxrpt user defined and no secret, I can connect as an "unauthenticated" client. With an invalid secret defined, the connection fails, and with a valid secret, the connection succeeds as an "authenticated" connection.

So, yes, it appears to work ok as a single user, even if it is templated, but no template user file exists.

How to handle all this with the installer script... I don't know how that all works.

[Allan-N]

Scrolling back up to Mar 26 comments, the intent is to put those .conf files in /etc/asterisk/custom... exactly where would be up to your discretion, but /etc/asterisk/custom/iax would seem like a reasonable place.

I agree. And, using /etc/asterisk/custom/iax would also follow the convention we are using with the asl3-menu customizations that use custom/rpt, custom/simpleusb, ...

I did some testing with iax.conf on a current distribution.

If I add the bang to template the instance: [iaxrpt]!, I can connect fine with the random generated password. With or without the #tryinclude... line didn't make any difference.

...

So, yes, it appears to work ok as a single user, even if it is templated, but no template user file exists.

Great!

How to handle all this with the installer script... I don't know how that all works.

Sadly, the top-level asterisk "Makefile" looks to be simple minded. But, I should be able to move the custom/iax .conf files a bit deeper with our asl3-asterisk project. I'll put that on my TODO list.