[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