[asterisk-dev] AES-GCM mode SRTP

[Kristian Kielhofner]

Hi,

  Really digging in the crates for this one!  As of yesterday
FreeSWITCH supports AES-GCM mode with SRTP:

http://jira.freeswitch.org/browse/FS-5937

  We have a patch for pjsip, which leaves Asterisk as one of the few
open source RTP/SRTP implementations I care about without support for
this.  Any more interest?

Thanks!

On Mon, Nov 11, 2013 at 2:16 PM, Kristian Kielhofner <kris at kriskinc.com> wrote:
> On Mon, Nov 11, 2013 at 12:00 PM, Matthew Jordan <mjordan at digium.com> wrote:
>>
>>
>>
>> The patch looks good for the parsing/understanding of the attribute. Thanks
>> for the contribution!
>
>   Thanks!
>
>> Unfortunately, Asterisk is a little goofy in that it assumed there were only
>> two tag lengths possible (32 or 80). You can take a look where it parses out
>> the encryption_taglen parameter here in chan_sip:
>>
>> } else if (!strcasecmp(v->name, "encryption_taglen")) {
>> ast_set2_flag(&peer->flags[2], !strcasecmp(v->value, "32"),
>> SIP_PAGE3_SRTP_TAG_32);
>
>   This assumption is very common.
>
>> You'd probably want to eschew the usage of flags and instead store the tag
>> length value directly on the peer. You'd then have to extract that before
>> calling crypto_get_attrib/ast_sdp_srtp_get_attrib - those should probably be
>> updated to take in an enum value specifying the tag length, as opposed to a
>> binary option.
>>
>> Similarly, res_pjsip would need to get updated to parse out a tag length
>> instead of having a 'use 32 instead of 80' option.
>
>   The draft for AES-GCM mode with SRTP specifies 128, 192, and 256 bit
> modes (as does RFC 6188) so ideally we'd move from specifying the tag
> length to specifying the full crypto suite (but that's probably
> another issue for another day).  Also, I haven't investigated how
> Asterisk handles the SDP offer/answer behavior of multiple crypto
> offers on incoming/outgoing invites.
>
>   Anyway, for 128 bit AES-GCM specifying the tag length is fine and as
> you can see that's what my code does.  Updating the parsing of the
> configs for chan_sip and pjsip is a TODO.
>
>   Speaking of TODOs, the autoconf portions of Asterisk will need to be
> updated to check for EVP_EncryptInit, EVP_aes_128_ctr, and
> EVP_aes_128_gcm in OpenSSL (requires 1.0.1 or later) and
> crypto_policy_set_aes_gcm_128_8_auth in libsrtp.  I haven't started on
> any of this.  In the code itself, should AES-GCM mode and it's
> required dependency on OpenSSL/libsrtp be a define?
>
>> In both cases, some care would have to be taken to ensure that DTLS is also
>> configured correctly - I'm not sure if it can use the AES-GCM option as
>> well.
>
>   The AES-GCM draft does specify the SRTP protection profiles for use with DTLS:
>
> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-10#page-24
>
>   Unfortunately I haven't even started to get in to the DTLS code in Asterisk.
>
> --
> Kristian Kielhofner



-- 
Kristian Kielhofner