Summary:ASTERISK-17895: [patch] chan_sip encryption attempt srtp / set auth taglen
Reporter:Gregory Hinton Nietsky (irroot)Labels:
Date Opened:2011-05-20 03:44:09Date Closed:2011-09-20 12:35:19
Versions:Frequency of
Environment:Attachments:( 0) global_srtp.dif
( 1) global_srtp2.dif
Description:Enable the ability to set the encryption tag length with SRTP.
Comments:By: Gregory Hinton Nietsky (irroot) 2011-05-20 07:22:58

ok adding onto this or as a alternative there is a incompatability problem with snom phones where they use 32 not 80 i sugest encryption=yes/no/32bit

By: Gregory Hinton Nietsky (irroot) 2011-05-20 12:27:35


By: Bob Beers (bbeers) 2011-05-20 14:09:42

Related to https://issues.asterisk.org/view.php?id=18674

Please also see this thread:

I have neglected this issue since a couple of months ...
The last patch I put on issue tracker still had some
problems from testers, but I am no longer at the job
where I had easy access to develop and test.
I thought the issue was soon going to be addressed
"from the inside", but as always, things seldom go
exactly as planned/hoped.

By: Gregory Hinton Nietsky (irroot) 2011-05-21 02:52:48

@bbeers thx ill look into your wotk my patch does not yet work ill look at what you done bonus is im able to test it ...

By: Gregory Hinton Nietsky (irroot) 2011-05-23 04:26:10

Ok update on SNOM using user_auth_tag = off you can have the phone work with 80bit authtag.

By: Leif Madsen (lmadsen) 2011-05-23 10:16:45

Marked as Confirmed. Please find me on #asterisk-bugs (or another bug marshal) to update this to Ready For Testing when the config options are finalized and it is ready for testing.

By: Malcolm Davenport (mdavenport) 2011-05-23 10:47:49


If we go the two option route, then it might make sense to name them:


RFC 3711 calls them tag bits, so we could do that or maybe:


Or underscores, or whatever.

By: Gregory Hinton Nietsky (irroot) 2011-05-23 11:28:37

it must be a _ to make it comaptible with realtime.

encryption_taglen=.... [default 80]

By: Gregory Hinton Nietsky (irroot) 2011-05-23 13:02:04

new patch uploaded to RB ready for review.

By: Bob Beers (bbeers) 2011-05-23 15:14:05

I am not trying to be obnoxious, but IMO this
patch seems to encompass now three separate issues.
Perhaps three separate patches/discussions would be
in order?

<li>Global "encryption" param vs per peer,
How does this affect incoming calls?
What advantage does it provide over status quo?</li>
<li>New global encryption option "try",
There was at one time a per peer SRTP flag,
"SRTP_ENCR_OPTIONAL", that seems unused in current
code.  Did this serve the same purpose?
Can/should it be resurrected before introducing a
new option?  Why was it obsoleted but not removed?</li>
<li>Ability to choose auth_tag length of 32.
This is a topic I have actually spent some time
considering.  This approach is interesting -- to
specify just the SRTP auth_tag length of the
crypto_suite.  I provided a similar mechanism
back in Jan/Feb timeframe, and I was told that
it was confusing to introduce a new parameter,
that it would be preferred to simply add new
options to the set of valid encryption values,
{yes|no}, to specify the specific crypto_suite
to use, and let 'yes' be backwards compatible
with the current default AES_CM_128_HMAC_SHA1_80.
Careful reading of RFC 4568 indicates that there
are only 3 crypto_suite combinations defined for

6.2. Crypto-Suites

  The SRTP crypto-suites define the encryption and authentication
  transforms to be used for the SRTP media stream.  The SRTP
  specification has defined three crypto-suites, which are described
  further in the following subsections in the context of the SRTP
  security descriptions.  The table below provides an overview of the
  crypto-suites and their parameters:

  |                     |AES_CM_128_  | AES_CM_128_  | F8_128_       |
  |                     |HMAC_SHA1_80 | HMAC_SHA1_32 |  HMAC_SHA1_80 |
  | Master key length   |   128 bits  |   128 bits   |   128 bits    |
  | Master salt length  |   112 bits  |   112 bits   |   112 bits    |
  | SRTP lifetime       | 2^48 packets| 2^48 packets | 2^48 packets  |
  | SRTCP lifetime      | 2^31 packets| 2^31 packets | 2^31 packets  |
  | Cipher              | AES Counter | AES Counter  | AES F8 Mode   |
  |                     | Mode        | Mode         |               |
  | Encryption key      |   128 bits  |   128 bits   |   128 bits    |
  | MAC                 |  HMAC-SHA1  |  HMAC-SHA1   |  HMAC-SHA1    |
  | SRTP auth. tag      |    80 bits  |    32 bits   |    80 bits    |
  | SRTCP auth. tag     |    80 bits  |    80 bits   |    80 bits    |
  | SRTP auth. key len. |   160 bits  |   160 bits   |   160 bits    |
  | SRTCP auth. key len.|   160 bits  |   160 bits   |   160 bits    |
The cipher and the SRTP auth. tag are the only parameters that are
not constant for all three suites.  There is mention of overriding
the lifetime setting, but that would be another separate issue, and
is possibly being addressed here: https://issues.asterisk.org/view.php?id=19339

By: Gregory Hinton Nietsky (irroot) 2011-05-24 00:13:11

1) having this a global option with a "try" option will allow IP based calling to use SRTP this in my case will be inter branch and enum calls.

2)SRTP_ENCR_OPTIONAL is a flag set on the srtp struct and is unused the "try" option is a per peer/pvt option that will prevent failure when the request is not met most phones have got a "attempt" / "enforce" option this is a extension of this into asterisk

3)i have not seen how to implement F8 with libsrtp it seems it is not supported this is also listed as a optional requirement if this is supported it would be great to add it to asterisk.

the consensus seems to be adding a option "encryption_taglen" defaults to 80 and accepts 32 this will use the 32bit version in a outgoing invite if set
the other part of the equation is to respond to a INVITE with the same taglen so if i get a 32bit taglen respond with 32bit this is built into the patch.

it would be nice to offer both options in a invite and extend asterisk to work with multiple offers once this is settled the patch you had does work toward this and its worth looking at again there is also a patch to ignore offers with 0 port.

By: Leif Madsen (lmadsen) 2011-05-24 17:06:21

OK, this should not be added as a global option to chan_sip. This should be a peer only level setting because the only options that should go into [general] are things that should be directly manipulating chan_sip, and not peers within the chan_sip. For that, you should be using the templating system.

So basically, we won't add peer level options to the [general] section just to enable a default for peers when that can be set within the templating system available within all Asterisk configuration files.

By: Gregory Hinton Nietsky (irroot) 2011-05-24 23:44:27

lmadsen okies no problem ill rework it easy enough also to let you know that have all sites phones working with SRTP next step is to deploy certs per phone for TLS with the asterisk server been the CA

By: Leif Madsen (lmadsen) 2011-05-25 06:29:16

The topic and description should probably be updated to reflect what the patch is trying to do now (basically setting type of encryption tagging, right?)


By: Gregory Hinton Nietsky (irroot) 2011-05-25 06:33:40

im with this change to "chan_sip encrytion attempt srtp / set auth taglen"

have not had chance to work on anything yet today may come latter.

By: Leif Madsen (lmadsen) 2011-05-25 10:17:36

I guess the option might be something like:

encryption_authtag_len={32,80}   ; set the authentication tag bit strength
                                ; defaults to 80

By: Gregory Hinton Nietsky (irroot) 2011-08-27 02:29:09.076-0500

Updated the reviewboard patch to remove the "attempt" srtp bits and focus on fixing the bug with using the incorect taglen.

By: Gregory Hinton Nietsky (irroot) 2011-09-14 07:50:30.077-0500

the taglen in the incoming invite always is used outgoing invites will have the configured taglen [default 80] this fixes a serious interop issue and bug where the taglen was always set to 80 regardles of the incoming invite.
also there was no way to set the taglen for a new invite.

By: Gregory Hinton Nietsky (irroot) 2011-09-20 12:35:19.815-0500