[asterisk-dev] Asterisk 1.8.4 SIP TLS/SRTP - Crypto Lifetime

[Dwayne Hubbard]

While working on getting Asterisk 1.8.4 to communicate with a Sangoma
Express Gateway using SIP TLS/SRTP, I saw the messages below on the
Asterisk CLI while the Sangoma side (thanks Ryan Mayer!) experienced a
call with no audio.

[May 20 13:45:07] NOTICE[25505]: sip/sdp_crypto.c:254
sdp_crypto_process: Crypto life time unsupported: crypto:1
AES_CM_128_HMAC_SHA1_80
inline:FZs8uIicFn4IfQxRs8xFi8U2yZJD84WluYoG5yZT|2^31

[May 20 13:45:07] NOTICE[25505]: sip/sdp_crypto.c:265
sdp_crypto_process: SRTP crypto offer not acceptable

[May 20 13:45:07] WARNING[25505]: chan_sip.c:8610 process_sdp: Can't
provide secure audio requested in SDP offer

The call attempts failed because the optional 'lifetime' component was
specified in the SRTP key parameter.  RFC 4568, section 6.1 SRTP Key
Parameter, states:

  SRTP security descriptions define the use of the "inline" key method
  as described in the following.  Use of any other keying method (e.g.,
  URL) for SRTP security descriptions is for further study.

  The "inline" type of key contains the keying material (master key and
  salt) and all policy related to that master key, including how long
  it can be used (lifetime) and whether it uses a master key identifier
  (MKI) to associate an incoming SRTP packet with a particular master
  key.  Compliant implementations obey the policies associated with a
  master key and MUST NOT accept incoming packets that violate the
  policy (e.g., after the master key lifetime has expired).

  ...

  The second field is the OPTIONAL lifetime of the master key as
  measured in maximum number of SRTP or SRTCP packets using that master
  key (i.e., the number of SRTP packets and the number of SRTCP packets
  each have to be less than the lifetime).  The lifetime value MAY be
  written as a non-zero, positive decimal integer or as a power of 2
  (see the grammar in Section 9.2 for details); leading zeroes MUST NOT
  be used.  The "lifetime" value MUST NOT exceed the maximum packet
  lifetime for the crypto-suite.  If the lifetime is too large or
  otherwise invalid, then the entire crypto attribute MUST be
  considered invalid.  The default MAY be implicitly signaled by
  omitting the lifetime.

Let me first state that I have a week of TLS/SRTP experience and spent
about and hour in RFC 4568, so what I'm about to say may be completely
wrong and there may be a horrible reason not to use my patch even in a
controlled environment (please tell me!).  I'm writing this email to
find out if there is a horrible reason not to do this.

I have provided a patch at:

https://issues.asterisk.org/view.php?id=19339

The patches attached to this issue add a 'ignorecryptolifetime'
(Ignore Crypto Lifetime) option to sip.conf for Asterisk 1.8.4 and
trunk.  This functionality is disabled by default, but when enabled it
will tell Asterisk to ignore the crypto lifetime key component if one
is specified instead of rejecting the SRTP crypto offer.  Using this
option I was able to successfully make TLS/SRTP calls to the Sangoma
Express Gateway.  This patch would not be necessary if Asterisk
supported crypto lifetime OR if the Sangoma Express Gateway provided
an option to disable the lifetime specification (it appears that it
does not).

One of the reasons that I feel like this patch is acceptable with the
current Asterisk TLS/SRTP implementation is because Asterisk has no
crypto lifetime support and this patch enables successful TLS/SRTP
calls to destinations specifying a crypto lifetime.  It should be
noted that this patch enables RFC 4568 non-compliance if the
destination specifies a low lifetime and Asterisk continues to accept
incoming packets after the lifetime has expired, but in my controlled
environment I know that the lifetime being specified is an extremely
large number.

In any case, this functionality is available at the URL above if
anyone is interested.

-Dwayne.