VoIP Mailing List Archives

[digium at private-addr...]

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.

[stotaro at totarotechn...]

Wireshark. 


On Fri, Apr 4, 2014 at 11:13 AM, Elliott W <digium@private-address.info (digium@private-address.info)> wrote:

[digium at private-addr...]

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@totarotechnologies.com (stotaro@totarotechnologies.com)> wrote:

[stotaro at totarotechn...]

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@private-address.info (digium@private-address.info)> wrote:

[digium at private-addr...]

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 <stotaro@totarotechnologies.com (stotaro@totarotechnologies.com)> wrote:

[digium at private-addr...]

Any ideas?  Still hoping..



On Sun, Apr 6, 2014 at 12:03 AM, Elliott W <digium@private-address.info (digium@private-address.info)> wrote:

[digium at private-addr...]

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@private-address.info (digium@private-address.info)> wrote: