[Asterisk-Security] Encryption costs (was: Supporting Security List)

John Todd jtodd at loligo.com
Sun Aug 7 20:06:23 CDT 2005


Let me throw my $.02 in here as "opinion statements":

0) Most people don't recognize that they need or want encryption, and 
will not be interested in it or activate it unless it is 
"on-by-default."  Witness security issues with a large software firm 
located in the Pacific Northwest.  Asterisk is clearly moving towards 
large-scale deployment, and security is only given lip-service by 
most users.

1) If the only encryption mechanism included in Asterisk _directly_ 
costs money in any use case of Asterisk, then that model is 
fundamentally flawed.  Companies will not adopt something that nobody 
uses, and nobody will use anything that a viable number of commercial 
endpoints do not support.  This can be proven wrong in some 
circumstances, but is typically true.  I speak from direct experience 
in quite a few ITSP and enterprise platforms; the attention to the 
user base vs. cost is acute.

2) Indirect security mechanisms that cost money are acceptable, as 
long as there are alternate no-cost solutions available.  I'm 
thinking directly of certs here, where a root cert at a 
"commonly-recognized" authority costs $, but it is possible to have 
your own zero-cost root cert with much more limited recognition.

3) All code in Asterisk should be GPL.

4) Asterisk should include in it's base distribution at least one 
strong method for encrypting signalling and media channels in IAX. 
Asterisk should (not necessarily at the same time as IAX) support 
RFC-standard encryption for SIP and RTP streams, using such protocols 
as TLS, S/MIME, and SRTP.

5) Encryption methods should be "plug-able" in any protocol (IAX, 
SIP, others) allowing for third-party non-GPL encryption routines to 
be installed easily if desired by the end user.

6) Any encryption code integrated into the distribution of Asterisk 
must be included as source code, and not as a pre-compiled binary or 
downloaded third-party add-on.  It is possible for companies to 
create such non-distribution add-ons to be used at the arrangement 
and discretion of the Asterisk administrator, but they must comply 
with the GPL.

7) Encryption must be enabled by default in standard configurations 
in order to gain wide acceptance.

8) Encryption-capable systems should speak to other 
encryption-capable systems when possible, and should fall back to 
non-encrypted media/signalling streams if an encrypted conversation 
cannot be established, and a warning should be logged to the console. 
This should be the default behavior.

9)  It should be possible to alter the default configuration such 
that fallback to non-encrypted methods do not happen.

10) If a key authority of some type is required for key registration, 
then the key authority must have a charter and representative body of 
governance which is created of members of the Asterisk development 
and user community.  Most likely, the key authority should be a 
non-profit and not associated with any commercial enterprise.



More information about the Asterisk-Security mailing list