[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