VoIP Mailing List Archives

[oej at edvina.net]

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

[email at mattruby.com]

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:

[oza-4h07 at myamail.com]

2008/2/13, Johansson Olle E <oej at edvina.net>: