[asterisk-dev] SRTP implementation

John Todd jtodd at loligo.com
Mon Apr 23 19:37:15 MST 2007


At 8:22 PM +0200 2007/4/23, Olle E Johansson wrote:
>23 apr 2007 kl. 19.55 skrev Russell Bryant:
>
>>John Todd wrote:
>>>To morph this into a -dev thread: if this patch were to become 
>>>(again) useful and error-free, is there any objection or 
>>>usefulness in adding it to TRUNK?  Personally, I think there is, 
>>>if there is a method by which SRTP can be activated or 
>>>de-activated from within the dialplan based on prior shared 
>>>secrets.  
>>>However, I have heard others disagree and object that without 
>>>signalling-based secure key exchange, SRTP is not worth the 
>>>effort.  Opinions?
>>
>>I agree with you.  I think that is a reasonable approach.  I can't 
>>speak for the quality of the patch itself as I have not reviewed 
>>it.  But, if it works, I would guess that it would not be too bad 
>>to get it into trunk.
>
>Kevin and I earlier decided that we wanted to delay this until we 
>had a complete security solution, with signalling based secure key 
>exchange ;-)
>
>/O

I'm uncertain if this delay is appropriate, given that this patch has 
been in process since October of 2005 and there has yet to be any 
other suitable solution.  While it may be the case that further work 
is being done (bravo!) to create a replacement for chan_sip, that 
does not negate the work that Mikael has done if his patch indeed 
does what is intended.  Certainly a good start towards encouraging 
encryption is to get one half of the encryption problem solved for 
the most popular protocol, no?   When the new SIP architecture is put 
in place at some point in the future, perhaps there will be an 
Asterisk-based audience who is already familiar with using basic 
encryption and who will applaud the additional functionality.

And I also disagree that there is not secure key exchange.  Having 
shared secrets is secure (though it does not scale) and it seems 
presumptive to not include a feature because it possibly could be 
misconfigured to create an unsecure system.  If that methodology were 
the case, Asterisk would still be functioning as a Zap-only 
environment with a rather large backlog of patches waiting for final 
approval.   And while it does not scale without the automatic key 
sharing, there are many instances where that does not matter.  As an 
analogy: I'm certain more than 90% of the world's routers use default 
and/or static routes, and that seems to suit their operators just 
fine.

JT


More information about the asterisk-dev mailing list