[asterisk-bugs] [JIRA] (ASTERISK-29128) res_srtp: Authentication failure after hold/unhold

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-29128:
---------------------------------------

    Attachment: snom_changed_srtp_suite_16.patch
                snom_changed_srtp_suite_13.patch
                snom_changed_srtp_suite_13_256.patch

Well, you can do one thing: Could you not rely on me? This issue here is a perfect example of what is wrong within the VoIP/SIP/SDP/RTP ‘industry’. For example, I am not an employee but just a contributor to the Asterisk project. Furthermore, I am not a professional but just a hobbyist, not gaining a penny. From an objective point of view, I have no motivation here. Therefore, I cannot be expected to be the driver of this issue through the various layers. Is it a problem for the Asterisk project, is it a problem for Digium/Sangoma, is it a problem for Snom? Or is it even an issue in the specification itself, which layer (SDP or SDES-sRTP), and therefore which RFC exactly? Or is this not a software bug but an interoperability issue for SIP implementers in general, and we would need clarification via a ‘best practice’ RFC? Something is wrong for sure; the call has no audio after resume. Now, what is the correct way to fix this? Should an end-user (like me) be the driver because he is affected by this?

Back to some facts: Over the holidays, I went through [my collection|https://www.traud.de/voip] of SDES-sRTP enabled desk phones. The (bad or good) news, I did not face this issue with any other software platform. The (good or bad) news, I found a lot of other issues because of this call scenario. And I understand even less how the protocol designers thought about this scenario. Near to every implementation does it differently; the very same call scenario.

The worse news, the change for ASTERISK-28903 is not the cause. To test my statement, undo the change as you did already, configure your Asterisk to send not an 80 but 32-bit tag, configure your Snom to use not a 32 but 80-bit tag on default. Now, when you resume, you have exactly the same outcome: Your Asterisk cannot authenticate the sRTP packets from your Snom anymore.

It was pure luck that the scenario Call Hold/Resume with SDES-sRTP worked. The change for ASTERISK-28903 just unveiled this software bug. Before ASTERISK-28903, {{srtp->flags}} contained the flag for 
* AST_SRTP_CRYPTO_TAG_80 and
* AST_SRTP_CRYPTO_TAG_32

at the end of {{ast_sdp_crypto_process(.)}}. This was and is silly because both flags are mutually exclusive. When you set debug level 1, you see ‘SRTP remote key unchanged; maintaining current policy’. The key did not change. That is correct. However, the crypto suite changed.

Now, let us change the key when the suite changed. Attached, you find three patches, one for
* Asterisk 13,
* Asterisk 13 with the patch for ASTERISK-26190 applied,
* Asterisk 16 and newer

It worked here in all scenarios: Asterisk with 32 or 80 bit as default, Snom with 32 or 80 bit as default. Please, give it a try. However, keep the call going for more than 22 minutes (0xffff × 20 milliseconds), then do the first Call Hold/Resume. Ta-da! Your Asterisk cannot authenticate the sRTP packets from your Snom anymore. The cause is the roll-over counter (sRTP-ROC). In the Snom desk phone, the ROC is 1 now because the RTP-SEQ wrapped once. In Asterisk, the ROC gets reverted to 0 because (with the attached patch) Asterisk calls crypto_activate(.) on Call Hold. Again, does a specification exist which states what to do with the sRTP-ROC in such a scenario: Is 0 or 1 correct?

I have not decided yet whether to submit that patch into Asterisk (if you like it, go for it and go for the review process). Although the patch is correct and does not do any other harm, it just hides the issue further. Now, you have to call at least 22 minutes, put the call on hold, and when you resume, you face the issue. We are just hiding a software issue being there for more than 15 years.

*Long story short*:
Who is the driver who goes through all those questions and answers them together with the VoIP/SIP/SDP/RTP community? With Snom, I filed ticket [#42056|https://helpdesk.snom.com/support/tickets/42056].
Until resolved, I recommend configuring your Snom to use the same authentication bit length on default as your Asterisk does.

> res_srtp: Authentication failure after hold/unhold
> --------------------------------------------------
>
>                 Key: ASTERISK-29128
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29128
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_srtp
>    Affects Versions: 16.13.0
>            Reporter: laszlovl
>              Labels: patch
>         Attachments: filtered.log, snom_changed_srtp_suite_13_256.patch, snom_changed_srtp_suite_13.patch, snom_changed_srtp_suite_16.patch, snom-srtp-debug-filtered.log
>
>
> As simple as the title indicates. Put an SRTP call on hold, unhold it, and Asterisk starts logging "SRTP unprotect failed on SSRC 1509410849 because of authentication failure" afterwards. No more audio is transmitted.
> Traced the problem to commit https://github.com/asterisk/asterisk/commit/c00b032bbfc14f40537989477229f189a1b529d7 (ASTERISK-28903), without it everything works fine.
> Asterisk 16.13, libsrtp 1.5.4.



--
This message was sent by Atlassian JIRA
(v6.2#6252)