[VOIPSEC] Security VoIP Project
dwing at fuggles.com
Thu Feb 4 22:09:27 GMT 2010
On 2/3/2010 12:01 PM, Rick Porter wrote:
> The Wikipedia SRTP pages used to have a good summary until someone decided
> there was too much backdoor marketing on the page. Here is some of my
> information which reflects the "status", as I saw it, from last spring.
A significant omission on that Wikipedia page: it doesn't mention
DTLS-SRTP (which is the IETF's current favorite for keying SRTP,
as decided at the RTPSEC BoF at IETF68 (Prague, March 2007),
> If you're looking for SRTP and don't care about the particular key exchange,
> then Security Descriptions (RFC-4568) is probably the best bet. It seems to
> have the most widespread acceptance. RFC-4568 says the signaling MUST be
> encrypted, because it effectively passes the traffic encryption keys around in
> the clear (yes, there is some derivation but anyone with access to the SDES
> info has enough to decrypt the call). RFC-4568 leaves the flavor of signaling
> encryption (e.g. IPSec, TLS, SMIME) upto the endpoint.
> Not all key exchanges are equal! Some other key exchanges (e.g. MIKEY, ZRTP,
> Sipura) can use public key techniques to protect the key exchange, and
> therefore do not require encrypted signaling.
> I do not have experience with ZRTP, but the protocol defines a Diffie-Hellman
> key exchange in the media stream with some options for "binding" to the
> signaling. You should be able to find implementations of that, but I do not
> know how many endpoints/servers have implemented ZRTP.
http://zfoneproject.com/partners.html has a list.
All the information you need about ZRTP -- and more -- is at
> I did a fair amount of interoperability testing with various SRTP
> implementations while working on the Acme/Covergence product. Not all products
> strictly adhered to the published standards, and some products had additional
> conditions that had to be met. Each product has it's own configuration that
> drives some of those requirements (which may override the IETF spec
> requirements). The product offerings were changing too rapidly for me to feel
> comfortable including any interoperability notes or commentary. I don't have
> specific model/version numbers, but here's my unscientific summary (in no
> particular order):
> 1. Counterpath: SDES/SRTP
> 2. Snom: SDES/SRTP
> 3. Aastra: SDES/SRTP
> 4. Polycom: SDES/SRTP
> 5. Siemens: MIKEY/SRTP (unencrypted MIKEY messages, required TLS)
> 6. Microsoft: SDES/SRTP using MKI, older clients had DES-CBC encryption
> 7. Linksys/Sipura: had it's own key exchange using public key techniques and
> their own "certificates" exchanged in SIP INFO messages. The actual encryption
> was AES-CM-128, but the authentication was with a full MD5-HMAC (instead of
> truncated SHA1-HMAC).
> 8. PhonerLite: SDES/SRTP
> 9. minisip: MIKEY/SRTP
Not all MIKEYs are compatible. The only mandatory-to-implement is
MIKEY-RSA, but there is no standard to obtain the called party's
certificate, which is necessary to send a MIKEY-RSA message.
http://en.wikipedia.org/wiki/MIKEY provides a summary of some of
the MIKEY key exchange methods; an endpoint that implements MIKEY-DH
cannot interoperate with an endpoint that implements MIKEY-RSA-R.
And, even though MIKEY-RSA is mandatory-to-implement, it is not
implementable on the Internet.
> On the infrastructure side, I worked on SDES/MIKEY with SRTP, the
> Linksys/Sipura SRTP, and the older Microsoft implementation. Beyond that, I
> have heard the following infrastructure has some version of SRTP and some key
> exchange (in no particular order):
> Please do not take this to be a definitive list -- I am sure that I have
> forgotten some.
> Good luck,
> Rick Porter
> Voipsec mailing list
> Voipsec at voipsa.org
More information about the Voipsec