Summary:ASTERISK-17899: Handle crypto lifetime in SDES-SRTP negotiation
Reporter:Dwayne Hubbard (dhubbard)Labels:
Date Opened:2011-05-20 15:07:41Date Closed:2015-02-25 15:15:41.000-0600
Versions:Frequency of
is related toASTERISK-20233 SRTP not working with some devices (Eg Grandstream gxv3175) - Message "Can't provide secure audio requested in SDP offer"
is related toASTERISK-22748 SRTP Crypto Offer With Lifetime Not Accepted
is related toASTERISK-17721 Incoming SRTP calls that specify a key lifetime fail
Environment:Attachments:( 0) dw-ignore-crypto-lifetime-1.8.4.patch
( 1) dw-ignore-crypto-lifetime-trunk-r320171.patch
( 2) lingon-srtp-key-lifetime-1.8.diff
Description:This functionality is disabled by default, but when enabled it will tell Asterisk to  ignore the crypto lifetime key component if one is specified.  Using this option I was able to successfully make TLS/SRTP calls to the Sangoma Express Gateway.  This patch would not be necessary if the Sangoma Express Gateway provided an option to disable the lifetime specification; but it appears that it does not.

Without this patch, any SRTP offers that specify the optional lifetime key component will fail.

This patch was also tested by Ryan Mayer (mantis user: 'hidden').  Thanks Ryan!


Here is a sample sip.conf entry:

Comments:By: Ryan Mayer (hidden) 2011-05-23 11:52:55

tested working on 05-20-2011

By: Alexandre Keller (alexandrekeller) 2011-08-31 22:14:47.982-0500

Any news on that? I've just installed Asterisk 1.8.6, enable SRTP on Audicodes 320HD, have applied the patch, but no success so far.

By: Manas (manas83) 2012-03-22 06:38:38.928-0500

i can not install this patch on asterisk, anybody can help

By: Mariano (mkunte) 2013-04-26 07:00:32.025-0500

In asterisk 1.8.17 does not work. Any idea?

By: Olle Johansson (oej) 2013-08-30 09:22:32.042-0500

The default lifetime in SRTP is 2^31 - if that's offered we should not reject the call regardless of this option.

By: Olle Johansson (oej) 2013-08-30 09:45:54.087-0500

SOrry, default for SRTP is 2^48 and SRTCP 2^31 according to RFC 4568.

By: Olle Johansson (oej) 2013-09-02 08:35:41.532-0500

"The lifetime of an SRTP AES master key for G.729 is more than 178,000 years (248/50 pps) for SRTP and more than 27 years (231/(50* 0.05) pps) for an SRTCP AES. Thus, re-key is not recommended for IP telephony. Instead, the session should be ended and a new one established." http://www.cisco.com/web/about/security/intelligence/securing-voip.html

I am trying to sort out how the SDP negotiation applies, since some document claim we have to answer with the same lifetime and the RFC is very unclear. I think we can safely confirm anything above 2^20 and just ignore the packet counters behind it... Not nice, but working.

As soon as I have a definitive answer, I'll update this issue.

By: Olle Johansson (oej) 2013-09-05 03:41:08.413-0500

Ok, I have done plenty of research and talked with friends in the IETF. Here's the outcome: The crypto key attributes are declarative, and not part of a negotiation. This means that if the other part sends us a lifetime and/or a MKI index we need to follow that when sending to them.
We do NOT have to send the attributes ourselves and the defaults will apply.

Just ignoring it is not a good option, hanging up i very bad. I beliveve we have packet counters in the RTP stack so that we can honour the lifetime if needed. The quick-and-dirty fix is just to accept anything above a certain treshold and hope that the other side will re-invite before that happens and give us a new key.

I would consider this code a bug in 1.8 that we need to fix in all maintained versions of Asterisk.

By: Olle Johansson (oej) 2013-09-12 06:46:53.512-0500

Started a branch called lingon-srtp-key-lifetime-1.8 to work on this.

By: Olle Johansson (oej) 2013-09-12 06:50:06.431-0500

Pointer to discussion on asterisk-dev and Matt's decision that this is a bug.

By: Olle Johansson (oej) 2013-09-18 13:41:28.529-0500

The Lingon branch now handle lifetime and MKI parameters.

We only accept lifetimes up to max for the crypto and higher than 10 hours for packetization of 20 ms (50 pps).

We only handle MKI with index 1.

We do not really bother with counting packets and reinviting at end of lifetime, so the min of 10 hours kind of takes care of most calls. If there are longer ones, we rely on the other side for re-invites.

It's still not perfect, but I personally think this is an improvement. A configuration option for minimum lifetime accepted could be added.

Please test this code with phones that you've had issues with! Thank you!

By: Olle Johansson (oej) 2013-09-19 03:51:27.110-0500

Uploaded a diff from my branch for Asterisk 1.8

By: Matt Jordan (mjordan) 2015-02-25 14:42:19.137-0600

Olle's branch was ported forward to 11/13, and put up for review here:
* https://reviewboard.asterisk.org/r/4419/
* https://reviewboard.asterisk.org/r/4418/

Tests for the Test Suite here:
* https://reviewboard.asterisk.org/r/4420

Much thanks to [~oej] for the Lingon branch and the work on this issue!