[asterisk-bugs] [JIRA] (ASTERISK-20219) IAX2 Call Encryption Fails with RSA authentication

[Michael Munger (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=211301#comment-211301 ] 

Michael Munger commented on ASTERISK-20219:
-------------------------------------------

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...)
                
> IAX2 Call Encryption Fails with RSA authentication
> --------------------------------------------------
>
>                 Key: ASTERISK-20219
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20219
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 1.8.11.1, 1.8.14.1
>         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
>            Reporter: Michael Munger
>            Severity: Minor
>         Attachments: iax2rsabug.tar.gz
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira