[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=217432#comment-217432 ] 

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

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

> 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 was sent by Atlassian JIRA
(v6.2#6252)