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

[Sean Bright (JIRA)]

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

Sean Bright commented on ASTERISK-20219:
----------------------------------------

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.

> 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: iax2-rsa-auth-with-enc.diff, 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)