If Asterisk does indeed use SECUREDIAL or similar as distinct from
DIAL, then DIAL should wrap SECUREDIAL for calls to a party that are
secure. This would parallel HTTP "GET" (or "POST") which use
the same
function entry for both secure and insecure connections, wrapping their
secure access inside generic access.
To continue the parallel, the dialstring should indicate whether
SIP/TLS (and otherwise for IAX) is to be used, which should allow the
DIAL function to determine whether to make a secure connection. To go
further, if SECUREDIAL is invoked on a dialstring which does not specify
a secure connection, that invocation should at least flag the insecure
connection attempt, or even fail with an exception.
I'm not sure that the SIP spec allows a request for an insecure
connection to be rejected with instructions for requesting a secure
call. But if it does, then the DIAL function should allow logic for
options on the retry, like just failing with exception report or a list
of dialstrings to retry. Or maybe just an extention to jump to with the
failure in a variable, for the dialplan/AGI/etc able to use that status
for logic on retry or fail.
In general, the closer the DIAL function works to familiar Web
retrieval functions, the more Web programming techniques will be
applicable to Asterisk programming.
On Wed, 2008-02-13 at 10:40 -0600,
asterisk-users-request at lists.digium.com wrote:> Date: Wed, 13 Feb 2008 15:22:10 +0100
> From: Johansson Olle E <oej at edvina.net>
> Subject: [asterisk-users] What is a "secure call"?
> To: Asterisk Non-Commercial Discussion Users Mailing List -
> <asterisk-users at lists.digium.com>
> Message-ID: <5A9E843A-1A2B-4C17-A333-AD8CA1D1B4EB at edvina.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Friends,
>
> The following mail was sent earlier to asterisk-dev and did not
> cause
> the amount of discussion I hoped it would.
> Now that we have a way to secure signalling in IAX2 and SIP in
> Asterisk svn trunk, we need to start working on
> the concept of a "secure call" - or does it really matter?
>
> In SIP, there's a specification for how I as a domain owner can
> request all calls to my domain to use
> SIP/TLS by using DNS NAPTR and SRV records. But how do I as a caller
> request a secure service?
> How do we place a secure call with DIAL? Do we need SECUREDIAL?
>
> Any ideas and thoughts on the subject are welcome!
>
> Regards,
> /Olle
>
> --------- Copy of earlier mail ---------
> (http://lists.digium.com/pipermail/asterisk-dev/2007-July/028377.html)
>
> To open a can of worms... :-)
>
> I'm involved in Phil Zimmerman's efforts to integrate Zrtp into
> Asterisk. At the same time we have code for SRTP that needs to
> be integrated.
>
> This means that we will add the concept of a "secure call" in
> Asterisk. At some point, I want to be able to build dialplans
> where I can manager security requirements on channels, like "this
> conference is protected and requires a secure channel".
>
> So, to make this easy, should we have a boolean flag and determine
> "this is a secure call according to Asterisk Community
> Security Standards" or how should we handle this? I think leaving
> it
> up to the admin is the proper way to go, but we
> also have several scenarios to consider
>
> 1. Encrypted signalling and media stream
> 1. Open signalling stream, key exchange in the open, encrypted media
> 2. Open signalling stream, secure key exchange, encrypted media
> 3. Secure signalling stream, un-encrypted media
>
> exten => _x.,n,gotoif(${ISSECURECALL(level6)} ? approved,1 :
> hangup,1)
>
> And to add to that, we have many different call scenarios.
>
> 1. Bridged call between two secure endpoints, Asterisk transcodes
> and
> have an unsecure media path
> 2. One-legged secure call between Asterisk and a phone (IVR)
> 3. SIP to ASterisk over IAX trunk to another Asterisk to SIP with
> SRTP/
> TLS and encrypted IAX - but open
> media path when going from SIP to IAX
>
> And yes, of course, this is not attempting to be a complete list at
> all.
>
> Can we simplify this and make it configurable? Do we want to?
>
> Can we implement the notion of a "trusted" PBX that we allow
being
> in
> the middle and "untrusted" PBXs
> that we want to avoid or that changes the security property of a call.
>
> As I said to Phil: "A PBX is designed to be a man-in-the-middle
> attack."
>
> There's certainly room for discussion, brainstorming and wild ideas
> here.
>
> /O
>
>
--
(C) Matthew Rubenstein