IAX2 Trunk Encryption

Home » Asterisk Users » IAX2 Trunk Encryption
Asterisk Users 6 Comments

Ok, I think I am 90%+ there.

Note: the configuration or status is the same on both sides unless otherwise noted.

I am using RSA keys for authentication and the calls are coming through as authenticated so I’m sure that part works.

The peer shows the “(E)” next to the status in Asterisk Info for the IAX2
peers

The trunk configuration contains:
encryption=yes

So here is my question, Calls stop flowing when I use the directive:
forceencryption=yes At the trunk level or higher does not matter, same effect.

So my question comes down to, are my calls getting encrypted and why does this directive cause them to fail, AND how can I tell.

Thanks.

6 thoughts on - IAX2 Trunk Encryption

  • That answered my question as to whether it WAS encrypted, I think, and the answer is no, the credentials are but all the rest is not. That just leaves the question of what I need to do to get it encrypted..

    Thanks.

  • I have.

    On the receiving side I had gotten:
    [2014-04-05 23:28:12] WARNING[1832] chan_iax2.c: Rejected connect attempt. No secret present while force encrypt enabled.

    I had no secret because I was using RSA authentication and didn’t think I
    needed it, so I added EXACTLY the same line on both sides (copy/paste). Now I get:
    [2014-04-05 23:30:42] NOTICE[1832] chan_iax2.c: Call Terminated, Incoming call is unencrypted while force encrypt is enabled.

    On the sending side I really get nothing useful:
    [2014-04-05 23:30:42] VERBOSE[2795][C-00000002] pbx.c: — Executing
    [s@macro-dialout-trunk:22] Dial(“SIP/comp-in-ch01-00000001″, ”
    IAX2/ch01_ch02/1234,300,Ttr”) in new stack
    [2014-04-05 23:30:42] VERBOSE[2795][C-00000002] app_dial.c: — Called IAX2/ch01_ch02/1234
    [2014-04-05 23:30:43] VERBOSE[2795][C-00000002] chan_iax2.c: — Hungup
    ‘IAX2/ch01_ch02-17634’
    [2014-04-05 23:30:43] VERBOSE[2795][C-00000002] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
    I modified the extension and the trunk name for security reasons, but without force encryption calls flow back and forth easily.

    These three directives exist on both sides:
    encryption=yes forceencryption=yes secret=mysecretcode

    So I’m kind of at a loss, I can see the options set, I can see:
    [2014-04-05 23:59:32] VERBOSE[1832] chan_iax2.c: — Accepting AUTHENTICATED
    call from xxx.yyy.zzz.aaa:
    when I DON’T have the force encryption set, so I can’t see what else I need to do..

    CEW

    On Fri, Apr 4, 2014 at 7:07 PM, Steve Totaro

  • I have some additional information, using wireshark and the IAX2 RFC I
    walked through the handshaking of the call. I did three different calls, RSA Authentication WITHOUT forcing encryption, RSA Authentication WITH
    forcing encryption, and “Clear Text” Authentication WITH forcing encryption. Keeping in mind that ALL setups have a secret set and it complains if you don’t when forcing encryption with RSA authentication.

    The RFC speaks to when the encryption information element is included in the NEW packed that following the AUTHREQ packet ALL communications are to be encrypted. When I used JUST a secret without RSA authentication I was able to see this behavior.

    In ALL cases whether using RSA or clear text secrets the Encryption format
    (0x2b) in the NEW packet was 0x8001, the RFC doesn’t tell me what that one is. It only lists 0x0001 as AES-128. But it is consistent across all the different calls. Now there are differences at the AUTHREQ packet. The Authorization method
    (0x0e) is 0x0004 RSA for the RSA ones and 0x0003 which is not listed in the spec but is likely clear text for the one not using RSA. This is clearly telling me that they are authorizing differently.

    As I said, with clear text authentication all packets following the AUTHREQ
    are encrypted, with RSA authentication they are NOT, I see the AUTHREP
    packet, the ACK of that packet and then depending on whether I had specified that encryption was required or not an ACCEPT (not required) or REJECT (was required). And I shouldn’t see anything after AUTHREQ.

    When it is accepted the call completes correctly, albeit without the encryption I desire. When it is rejected it gives me Cause (0x16) of “No authority found” and a Hangup Cause (0x2a) of “Facility not subscribed
    (0x32)

    *I am starting to think that this is a defect with the IAX2 protocol implementation, I have seen NOTHING indicating that you cannot use RSA
    authentication with IAX2 encryption BUT that does seem to be what IS
    happening. Nor have I found anything indicating this was a conscious design decision.*

    So does anyone have anything to add? How would I get this addressed as a bug?