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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=5413 
====================================================================== 
Reported By:                mikma
Assigned To:                otherwiseguy
====================================================================== 
Project:                    Asterisk
Issue ID:                   5413
Category:                   Channels/chan_sip/NewFeature
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     assigned
Target Version:             1.6.3
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 48491 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             2005-10-09 10:36 CDT
Last Modified:              2009-01-09 16:31 CST
====================================================================== 
Summary:                    [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 (17/12/2008): Branch against trunk is located here
http://svn.digium.com/svn/asterisk/team/group/srtp
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010129 Module SRTP can't loaded
====================================================================== 

---------------------------------------------------------------------- 
 (0097387) otherwiseguy (administrator) - 2009-01-09 16:31
 http://bugs.digium.com/view.php?id=5413#c97387 
---------------------------------------------------------------------- 
notthematrix: that just isn't the kind of decision that Asterisk should
make automatically for someone.  It is certainly possible to keep that kind
of list for yourself if that benefits your installation, but it isn't
something that is generally useful.  It would never be coded that way in
the source.  For one thing, it is possible to enable/disable SRTP support
in the phones, so it would possibly be out of sync for a bit.  It would be
trivial to manage yourself though, if you wanted to.

; run from a Dial with option M() so that we save the ability of the
callee 
[macro-set-secure]
exten =>
_X.,n,Set(DB(${MACRO_EXTEN}_secure)=${IF($[${CHANNEL(secure_media)}]?1:0)})

This would be a bit chattier than necessary since you'd really only need
to set the DB the first time the device was called, but you could wrap it
in a check first.  But the real problem is, we don't know *anything* about
the call we are about to make to the callee unless it is in sip.conf.  We
have to generate the invite either with, or without an encryption setting
and they are mutually exclusive (for now).  So at best you could generate a
list automatically, but if you don't know whether or not the phone supports
encryption when you are entering it into sip.conf, then you don't need
encryption on it anyway.

The *entire* problem is that there is no standards-compliant way to send a
request that says "encrypt this if you can, otherwise, I don't mind if it
isn't encrypted".  We can be liberal in what we accept from others, but
there is no way that we can send out something that everyone will accept. 
And I'm not willing to maintain multiple broken non-standard ways of
achieving the goal.

It seems to me that 1) Encrypting the caller if the request contains any
known method of negotiating encryption 2) Make it possible to determine
whether or not the device we are about to call understands a request for
encryption via SIPPEER(srtpcapable)--although I'm thinking this should be
SIPPEER(encryption) now and 3) The dialplan variable for whether or not to
send encrypted or not encrypted offers (both not both) should take care of
most of the use cases for encryption.

The example dialplan that I made above should do opportunistic encryption
as long as you have srtpcapable set in sip.conf.  Even if we made it
permissive and had an option to allow RTP when we requested SRTP, most
phones would just send a 488 Unacceptable Here to our request if they
didn't support SRTP. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-09 16:31 otherwiseguy   Note Added: 0097387                          
======================================================================