[asterisk-dev] SRTP implementation

[Olle E Johansson]

24 apr 2007 kl. 04.37 skrev John Todd:

> 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.

I did not say that I have this opinion now, but that was one of the  
reasons then.

The first issue, that kept it out of focus for a long time was the  
total lack of test responses from third parties and the fact that the
first patch did not have any hooks into chan_sip - Mikael later fixed  
that.

/O