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 <[email protected]> wrote: > On Mon, Nov 11, 2013 at 12:00 PM, Matthew Jordan <[email protected]> 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 -- _____________________________________________________________________ -- 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
