[asterisk-bugs] [Asterisk 0005413]: [patch] [branch] Secure RTP (SRTP)

Wed May 5 04:23:03 CDT 2010

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=5413 
====================================================================== 
Reported By:                mikma
Assigned To:                twilson
====================================================================== 
Project:                    Asterisk
Issue ID:                   5413
Category:                   Channels/chan_sip/NewFeature
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     assigned
Target Version:             1.8
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 48491 
Request Review:              
====================================================================== 
Date Submitted:             2005-10-09 10:36 CDT
Last Modified:              2010-05-05 04:22 CDT
====================================================================== 
Summary:                    [patch] [branch] Secure RTP (SRTP)
Description: 
This patch adds initial support for secure RTP using libsrt[1]. It can
be used in for example an implementation of the sdecriptions draft[2].

[1] http://srtp.sourceforge.net/srtp.html
[2]
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-12.txt

Update (16/03/2010): Branch against trunk is located here
http://svn.asterisk.org/svn/asterisk/team/group/srtp_reboot

*** IF TESTING, PLEASE USE THE ABOVE BRANCH AND NOT THE PATCHED ATTACHED
TO THIS ISSUE AS THEY ARE OUT OF DATE ***
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010129 Module SRTP can't loaded
====================================================================== 

---------------------------------------------------------------------- 
 (0121401) Joels (reporter) - 2010-05-05 04:22
 https://issues.asterisk.org/view.php?id=5413#c121401 
---------------------------------------------------------------------- 
Nokia's info:

• RFC 2246 The TLS Protocol Version 1.0:
o SIP stack does not support incoming TLS connections. Thus
proxies/registrars must support persistent TLS connections and be able to
use existing connections to deliver SIP requests to the clients (connection
reuse).
o The following cipher suites may be used when setting up the TLS
connection for SIP:
a. TLS_RSA_WITH_AES_256_CBC_SHA
b. TLS_RSA_WITH_AES_128_CBC_SHA
c. TLS_RSA_WITH_3DES_EDE_CBC_SHA
d. TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
e. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
f. TLS_RSA_WITH_RC4_128_SHA
g. TLS_RSA_WITH_RC4_128_MD5
h. TLS_RSA_WITH_DES_CBC_SHA
i. TLS_DHE_DSS_WITH_DES_CBC_SHA
j. TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
k. TLS_RSA_EXPORT_WITH_RC4_40_MD5
l. TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
m. TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
• RFC 3262 Reliability of Provisional Responses in the Session
Initiation Protocol (SIP):
o Secure VoIP session establishment using security preconditions uses
provisional responses sent by the UAS before the UAC has sent the SIP
message "PRACK". Implementation follows RFC 3262 to achieve end-to-end
reliability in transmitting such responses. Non-100 provisional responses
are sent reliably if the initial INVITE request contained either a
SUPPORTED or REQUIRE header field with the option tag "100rel".
• RFC 3711 The Secure Real-Time Transport Protocol (SRTP):
o The SRTP use is signaled by either having defined secure RTP transport
"RTP/SAVP" in an SDP media line or a=crypto as a media attribute in an SDP
document. "RTP/SAVPF" is not supported.
o Implementation supports RTP/RTCP stream authentication and encryption
with replay protection according to RFC 3711:
a. Same master key is shared with RTP/RTCP streams.
b. Section 8.1.1 Use of the <From, To> for re-keying is not supported.
• RFC 4568 Session Description Protocol Security Descriptions for Media
Streams:
o SDP attribute "crypto" is used to signal and negotiate cryptographic
parameters for media streams. This negotiation is secured by TLS.
o Implementation supports security descriptions according to RFC 4568 with
the following restrictions:
Implementation Specifications for Nokia S60 VoIP 17
Forum.Nokia.com
a. The following crypto suites are supported: AES_CM_128_HMAC_SHA1_80
(offered as default), F8_128_HMAC_SHA1_80 (supported if offered in the
initial INVITE), AES_CM_128_HMAC_SHA1_32 (supported if offered in the
initial INVITE).
b. The following session parameters are supported: KDR.
c. The following session parameters are not supported: UNENCRYPTED_SRTCP,
UNENCRYPTED_SRTP, UNAUTHENTICATED_SRTP, FEC_ORDER, FEC_KEY, WSH.
d. Re-keying is not recommended for IP telephony. Thus the optional
lifetime field of the SRTP key parameter is not supported. Key rotation
based on MKI is neither supported, though the MKI field in the SRTP key
parameter is accepted if only one inline key parameter is provided with
a=crypto attribute.
e. Section 6.4.2. Sharing cryptographic contexts among Sessions or SSRCs
is not supported.
f. Section 7.1.4. Modifying the session: Only key parameters can be
modified during the session. Initially negotiated crypto suite must remain
the same through all session modifications. If new offer cannot be
accepted, the old crypto parameters remain in place.
• RFC 5027 Security Preconditions for Session Description Protocol Media
Streams:
o The negotiation of cryptographic parameters when establishing a secure
VoIP session may take use of security preconditions, as defined in RFC
5027. The only supported precondition type is "sec". All the precondition
attributes ("curr", "des", "conf") are supported as are all the
precondition tags (strength, status, and direction). Strength is set as
"optional" in the initial INVITE to increase interoperability with other
vendors since security preconditions as a concept is published as a draft
at this stage. When an offer with preconditions is received, the strength
is increased to "mandatory" to prevent clipping effect and ghost calls from
happening. Security descriptions may also be negotiated without using
security preconditions if the other party does not support the concept. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-05 04:22 Joels          Note Added: 0121401                          
======================================================================