[asterisk-users] IAX2 Trunk Encryption

Sat Apr 12 00:37:44 CDT 2014

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?

On Mon, Apr 7, 2014 at 11:54 AM, Elliott W <digium at private-address.info>wrote:

> Any ideas?  Still hoping..
>
>
> On Sun, Apr 6, 2014 at 12:03 AM, Elliott W <digium at private-address.info>wrote:
>
>> 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 at 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 <
>> stotaro at totarotechnologies.com> wrote:
>>
>>> Have you enabled IAX2 debugging and tried some test calls?
>>>
>>> Thanks,
>>> Steve T
>>>
>>>
>>>
>>> On Fri, Apr 4, 2014 at 6:59 PM, Elliott W <digium at private-address.info>wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>> On Fri, Apr 4, 2014 at 12:59 PM, Steve Totaro <
>>>> stotaro at totarotechnologies.com> wrote:
>>>>
>>>>> Wireshark.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 4, 2014 at 11:13 AM, Elliott W <
>>>>> digium at private-address.info> wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> _____________________________________________________________________
>>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>>>>                http://www.asterisk.org/hello
>>>>>
>>>>> asterisk-users mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>>>>
>>>>
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>>>                http://www.asterisk.org/hello
>>>>
>>>> asterisk-users mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>>>
>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>>                http://www.asterisk.org/hello
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140412/b1a3fc4a/attachment.html>