At 2:22 PM -0700 7/18/06, Bret McDanel wrote:
On Tue, 2006-07-18 at 13:36 -0700, John Todd wrote:
I also understand that there has at least been some discussion with
Phil Zimmerman about ZRTP inclusion into Asterisk, though I don't
know who (if anyone) at Digium has been talking with him about it
(though I've brought it up enough with him to start looking like a
pest.)
As I understand the Zphone protocol, which may be wrong, its based off
his speech at etel, so I really havent looked at tech docs, but ... it
seems that its end to end encryption which uses normal sip devices
connected to a proxy running on a local system which then connects to
another similar proxy (directly or indirectly). This means that
asterisk can only do pass through, as such it shouldnt be that difficult
to implement it.
I may be wrong about my interpretation of this, however the hash that is
displayed would suggest that this is true (along with Phils comments
about using a normal sip device).
He implied but didnt actually state that pretty much anything that
bridges the two channels without transcoding will work - of course this
means that whatever payload that is used has to be supported (ie not
rejected, which may be listed as a totally different codec) and that its
stanard RTP othwerise.
Of course this does nothing for the signalling layer, but its a good
start.
My interpretations may be wrong, and I would appreciate someone who
knows correcting me if they are, as stated previously I really didnt
read anything just let my imagination run away during his speech trying
to visualize how it worked, and granted he only had 10 minutes or
whatever to talk about it.
It is mostly as you describe it. However, it fits the desire for an
opportunistic encryption system - if it's there, it will make itself
known. If it's not, your client could possibly continue working
without it in a less-secure fashion.
More notes on ZRTP:
ZRTP, like any encryption package, can be inserted into the middle of
any media stream and used to a significant advantage even when the
conversation is not "end-to-end" encrypted. For instance, I would
very much like to have my Asterisk server (with PRI cards) using ZRTP
to my SIP or IAX softphones on my laptop. I feel that the greatest
risk from interception is on the IP portion of the call, and so I
would be happy if Asterisk was a ZRTP speaker so that my calls to the
PSTN were at least encrypted on the most insecure leg.
This encryption level can be automated if the appropriate hooks are
installed into Asterisk. I would see three types of ZRTP support:
1) "Pass-through" mode where the media stream is not modified and
routes through Asterisk's RTP stack. The Asterisk server would of
course not be able to do things like record the call, play MOH, or
other media-specific tasks. I am uncertain about RFC2833, but I
suspect that too would be encrypted. Asterisk needs(?) minor
modifications to let the ZRTP encrypted packets go through when it
sees certain packet signature types. Of course, if for a particular
call Asterisk isn't in the RTP path then it works like a charm
already.
2) "Termination" mode, where a call from a ZRTP client would be
decrypted and the media relayed to a non-encrypted channel of choice
- IAX, Zap, SCCP, etc. This would involve giving the Asterisk server
a ZRTP identity. This, IMHO, would be the most common use of the
ZRTP stack, since the bulk of calls are to the PSTN on most systems,
and most PSTN providers don't have ZRTP (via Zap or normal RTP
SIP/IAX2 connections.) However, the server can typically be located
on a much more secure network segment than the client, so there is a
fairly good return on the encryption investment.
3) "Man in the Middle" mode, where Asterisk creates two separate
ZRTP legs to different ZRTP clients. While this sounds like a
security risk, it is actually a fairly desirable situation. Many
calls need to be recorded, or monitored for DTMF, or inserted into
app_conference for group discussion. Having each leg of the call
encrypted to the Asterisk server but not encrypted in an "end-to-end"
fashion would be frequent, I suspect. The users could still verify
that their calls were encrypted to the core, and interception would
not be possible except on the Asterisk server itself. This is just a
modified version of "Termination" mode and would not require any
additional programming I think, but is worth describing as it would
mimic an unauthorized intercept but would not be unexpected by the
end user.
I'm willing to put a few bucks towards ZRTP integration. I don't
know why Asterisk hasn't been the first platform tested - it really
does seem like an ideal candidate for a variety of reasons. Is there
anyone else working on this? I'm very sad that there is still only
weak support for encryption on a single protocol in Asterisk.
JT
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Security mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-security
