[Asterisk-Security] Opportunistic encryption

[Enzo Michelangeli]

----- Original Message ----- 
From: "Duane" <duane at e164.org>
Sent: Sunday, July 23, 2006 7:45 AM

[...]
> ZRTP doesn't seem like the best solution to me in any situation where you
> need to terminate the call without a person on the other end, for example
> calling your voicemail, or connecting to a VSP/ITSP that supports
> encrypted voice channels... (John Todd's email tried to point out other
> situation, but he left out a few such as transcoding between codecs etc)

Actually it's OK if you forgo authentication, directly proceeding
with SRTP using the key negotiated with Diffie-Hellman over special RTP
packets. This is fine for oportunistic encryption. Perhaps it would be make
sense to extend ZRTP by implementing an optional alternate authentication
method based on HMAC keyed by the SIP secret: something similar has been
proposed in MIKEY with Diffie-Hellman
(http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-11.txt ).

> Also there is a working SRTP branch out there

You mean David McGrew's BSD-licensed libSRTP
(http://srtp.sourceforge.net/srtp.html )? That's the same that Phil Z.'s
ZRTP implementation actually uses: I don't know about recent builds, but the
sources of Zfone I downloaded back in March did include it, apparently
verbatim. Unfortunately Phil Z's code itself is not opensourced, so his part
can't be directly embedded in Asterisk, at least without special
arrangements between him and Digium. But it proves that libSRTP can be
easily used as a building block in a ZRTP environment.

> and people seem to be testing it, if you throw ZRTP into the mix how long
> before it would be stable and be released as opposed to getting the SRTP
> branch added with opportunistic encryption?

ZRTP is just in-band (i.e., over RTP) D-H key negotiation (to be
authenticated verbally, as I said) followed by an SRTP session that uses
that key. It's innovative and slightly "heretical" because the key is
negotiated over the media streams rather that through the SIP signalling
path (as e.g. MIKEY does), but there are good reasons for that: signalling
is not end-to-end due to proxies, whereas RTP is, at most, more
transparently relayed. And, after all, RFC2833 has already sort of blazed
the trail in the use of special RTP packets for signalling purposes (as
an alternative to the SIP INFO method for DTMF data).

That said, I do agree on the fact that single-hop, opportunistic encryption
is not the application for which ZRTP was designed. ZRTP was born out of
desire for end-to-end security, and as we know the most popular SIP security
solution (cleartext session key passed over a SIP session itself secured by
TLS) is not end-to-end: in fact, no solution based on securing the entire
SIP channel can possibly be end-to-end, because intermediate proxies and
ALGs may need to inspect and modify the content of SIP packets to allow NAT
traversal etc.). But some design principles (preserve forward secrecy by
using D-H key negotiation; do not necessarily require a PKI) in my opinion
are applicable to our case as well. Perhaps, the above mentioned MIKEY with
D-H could represent an alternative. I believe that in MIKEY with D-H
authentication is presumed to be compulsory, but if the mikey-dhhmac is used
one can always fall back to unauthenticated D-H if the shared secret is
null.

The downside of it all is, alas, that public-key cryptography eats plenty of
CPU cycles. But if we'll avoid its use (e.g., by simply deriving SRTP
session keys from a HMAC of the IP addresses of the two peers keyed by the
SIP secret, or something like that) we'll lose forward secrecy and, worse,
won't be able to secure unauthenticated sessions, because in that case there 
won't be a shared secret from which the session key can be derived: good-bye 
opportunistic encryption.

Cheers --

Enzo