Summary:	ASTERISK-20219: [patch] - IAX2 Call Encryption Fails with RSA authentication
Reporter:	Michael Munger (drdamnit)	Labels:	patch
Date Opened:	2012-08-13 00:38:51	Date Closed:	2021-10-07 18:23:08
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:	1.8.11.1 1.8.14.1 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:	Server A Asterisk Version: Asterisk 1.8.14.1 Platform: Ubuntu 9.10 Server Server B Asterisk Version: Asterisk 1.8.11-cert4 Platform: Ubuntu 10.04.4 LTS	Attachments:	( 0) iax2-rsa-auth-with-enc.diff ( 1) iax2-rsa-auth-with-enc-updated.patch ( 2) iax2rsabug.tar.gz
Description:	When using RSA and key encryption for peering two servers together, the peers are able to authenticate using RSA encryption; however, call encryption fails with RSA encryption. In the attached debug information, please find documentation of the problem. (Wireshark frame numbers are appended to each even in parenthesis) 1. ServerB (oshea) makes a NEW request message to initiate the call. (#60) 2. Accordingly, ServerA (highpoweredhelp) replies with an AUTHREQ. The AUTHREQ DOES contain the username and authentication IE's as specified in rfc5456 6.2.7. (#63) 3. ServerB (oshea) replies with an RSA Challenge Result in an AUTHREP message. (#65) 4. ServerA then sends an ACK (#67) 5. ServerA immediatley sends a REJECT message with a "No authority found" cause. (#68) Notes: The pre-shared secret was identical on both sides. Given that the two peers are able to authenticate and register using these keys, the keys are deemed to be valid. In fact, if we remove forceencryption=yes and retain encryption=aes128 from iax.conf on both sides, the calls are authenticated using RSA and processed normally. However, despite having encryption=aes128, the calls are not encrypted: call information containing IP addresses of local stations as well as well identified voice packets are capturable with wireshark (tshark was used in this environment), and could be re-assembled into playable voice calls. Changing the configs to use auth=md5 instead of auth=rsa immediately fixes the problem with no other configurations, and also encrypts the calls properly.
Comments:	By: Michael Munger (drdamnit) 2012-08-13 00:40:06.103-0500 IAX traces, tshark / wireshark capture, config files, etc... By: John Schmidt (jschmidt) 2013-10-27 13:28:44.938-0500 This bug still exists as described in 11.6.0. By: Matt Jordan (mjordan) 2013-10-27 13:40:40.721-0500 The issue is still open. As such, it is not expected to be fixed in any version of Asterisk. By: Michael Munger (drdamnit) 2013-10-28 14:34:07.100-0500 Do you have a recommended alternative / workaround, or is this just the writing on the wall that IAX is going away? By: Matt Jordan (mjordan) 2013-10-28 15:12:40.333-0500 IAX isn't "going away". People still use IAX as well as develop for it. Support for IPv6 was added in Asterisk 12. Making the assumption that a single issue being open against a channel driver implies that support for said technology is going to end is a large and terrible leap in logic. By that extension: SIP is also clearly doomed. Issues are worked periodically by developers in the Asterisk community. If you'd like to have this issue addressed faster, you may want to consider posting a [bounty for this bug|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties] on the asterisk-dev mailing list. By: Michael Munger (drdamnit) 2013-10-28 15:19:09.895-0500 At one point, there was a lot of jittering about IAX not getting further development because (at the time) SIP was being so heavily adopted. This was a year or so after the IAXy was discontinued. Shortly thereafter, a lot of IAX ITSP providers went out of business. So, there was no terrible leap of logic here. I am a huge IAX proponent. I was just parroting what I had read a while ago. SIP is clearly doomed. It's stupidly engineered, hates firewalls, and requires a Gawd awful number of ports to be open just to use it. IAX is elegant, efficient, and just damned sexy. Long live IAX! I have considered a bounty or doing it myself. The point of my question was to simply ask - is this not getting worked on because some other support was added in its place? (Like... someone added AES512 so RSA has no plans of being worked on...) By: C. Elliott Whitlow II (ewhitlow) 2014-04-17 23:30:08.212-0500 This continues to be an unresolved issue.  Reading through the description this is EXACTLY my issue. By: Michael Munger (drdamnit) 2014-04-18 04:00:01.581-0500 With all the Big Brother NSA stuff that is going on, I wonder how many people are using this to protect their communications not knowing that it's not really being encrypted... By: Sean Bright (seanbright) 2014-07-23 07:16:34.572-0500 I've uploaded a *preliminary* patch for this issue on Asterisk 1.8: {{iax2-rsa-auth-with-enc.diff}} Because we are dealing with security & encryption, I would not recommend deploying this in production or on a large scale, but in my testing it _appears_ to work.  This patch needs to be applied to both the local server (oshea) as well as the remote server (highpoweredhelp). By: Sean Bright (seanbright) 2014-07-23 07:25:22.126-0500 An important point I neglected to mention: if a peer is updated with the aforementioned patch and the user is not, the user will crash when initiating the call. By: N A (InterLinked) 2021-05-18 20:15:31.809-0500 The diff from 2014 no longer seems to work because the code has changed enough that applying the patch adds code in the wrong places, causing compiler errors among other things. I've manually recreated Sean's patch from 2014 and it compiles fine now with Asterisk 18: iax2-rsa-auth-with-enc-updated.patch I've not been able to get RSA encrypted calls working properly yet. Without a secret on both ends, I continue getting hangup code 50 "Rejected connect attempt.  No secret present while force encrypt enabled.", which was in IAX2 even in Asterisk 1.8. If I require a secret on Switch B, Switch A crashes when making the call, similar to MD5 before that bug was patched this February. It looks like a secret (and a key) are required for RSA authentication + encryption, and I tried with a config like the OP's, but that gets me hangup code 0. If anyone has an example of a working config with this, that would be helpful to continue testing. By: Friendly Automation (friendly-automation) 2021-10-07 18:23:09.627-0500 Change 15934 merged by George Joseph: chan_iax2: Add encryption for RSA authentication [https://gerrit.asterisk.org/c/asterisk/+/15934|https://gerrit.asterisk.org/c/asterisk/+/15934] By: Friendly Automation (friendly-automation) 2021-10-07 18:23:25.831-0500 Change 15933 merged by George Joseph: chan_iax2: Add encryption for RSA authentication [https://gerrit.asterisk.org/c/asterisk/+/15933|https://gerrit.asterisk.org/c/asterisk/+/15933] By: Friendly Automation (friendly-automation) 2021-10-07 18:23:40.015-0500 Change 16369 merged by George Joseph: chan_iax2: Add encryption for RSA authentication [https://gerrit.asterisk.org/c/asterisk/+/16369|https://gerrit.asterisk.org/c/asterisk/+/16369] By: Friendly Automation (friendly-automation) 2021-10-07 18:23:50.661-0500 Change 15948 merged by George Joseph: chan_iax2: Add encryption for RSA authentication [https://gerrit.asterisk.org/c/asterisk/+/15948|https://gerrit.asterisk.org/c/asterisk/+/15948]