[asterisk-bugs] [Asterisk 0019335]: [patch] Should "encryption" be a global option ??

Asterisk Bug Tracker noreply at bugs.digium.com
Mon May 23 15:14:06 CDT 2011


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19335 
====================================================================== 
Reported By:                irroot
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   19335
Category:                   Channels/chan_sip/SRTP
Reproducibility:            N/A
Severity:                   trivial
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
JIRA:                       SWP-3490 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-05-20 03:44 CDT
Last Modified:              2011-05-23 15:14 CDT
====================================================================== 
Summary:                    [patch] Should "encryption" be a global option ??
Description: 
allow SRTP global setting in addition to per peer setting ??

this is a trivial patch ...

this also raises a janitor project sip.h has a G/D/P for the context of
the setting some global settings ie faxdetect are not marked G


====================================================================== 

---------------------------------------------------------------------- 
 (0135308) bbeers (reporter) - 2011-05-23 15:14
 https://issues.asterisk.org/view.php?id=19335#c135308 
---------------------------------------------------------------------- 
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?

1 - Global "encryption" param vs per peer,
How does this affect incoming calls?
What advantage does it provide over status quo?

2 - 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?

3 - 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
 SRTP,

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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-23 15:14 bbeers         Note Added: 0135308                          
======================================================================




More information about the asterisk-bugs mailing list