[asterisk-bugs] [JIRA] Status Changed to Waiting for Development: (ASTERISK-20219) IAX2 Call Encryption Fails with RSA authentication

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-20219:
------------------------------------

    Status: Open  (was: Triage)

> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira