[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