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

[Abdenasser Ghomri]

Dear Dwayne,

I have tested your Patch with Grandstream Phones which do not have the
option to disable the usage of the lifetime tag, the calls are being
established correctly and SRTP is being accepted however there is a delay
in receiving audio from Asterisk to the phone, it does take up to 4 sec to
start hearing the remote side on the Grandstream phone.

Can you please help to take a look into this issue to identify why there is
such a delay when using the "ignorecryptolifetime" options ?

Please find below a link to download the capture trace which show a simple
call from Grandstream to Asterisk echo test call using SRTP :

www.mediafire.com/?n307geci98vvm9k

Asterisk version used is 1.8.7.0 ( Also tested with previous version 1.8.4).

Thank you in Advance for your time.
Any additional info required please do not hesitate to let me know.

Best Regards,


On Fri, May 20, 2011 at 11:24 PM, Dwayne Hubbard
<dwayne.hubbard at gmail.com>wrote:

> 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.
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130606/244bf4a8/attachment-0001.htm>