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,
[EMAIL PROTECTED] wrote:
Date: Wed, 13 Feb 2008 15:22:10 +0100
From: Johansson Olle E [EMAIL PROTECTED]
Subject: [asterisk-users] What is a secure call?
To: Asterisk Non-Commercial Discussion Users Mailing List -
asterisk-users@lists.digium.com
Message-ID: [EMAIL PROTECTED]
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
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
