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

[N A (JIRA)]

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

N A edited comment on ASTERISK-20219 at 5/18/21 9:29 PM:
---------------------------------------------------------

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.

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.


was (Author: interlinked):
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.

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

> [patch] - 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, 13.18.4
>         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
>              Labels: patch
>         Attachments: iax2-rsa-auth-with-enc.diff, iax2-rsa-auth-with-enc-updated.patch, 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 was sent by Atlassian JIRA
(v6.2#6252)