[VOIPSEC] Security VoIP Project

[Dan Wing]

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),
http://www.ietf.org/proceedings/68/minutes/rtpsec.txt).

> 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 
http://zfoneproject.com

> 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.

-d

> 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):
> Ingate
> Sipera
> Siemens
> Nortel
> Asterisk
>
> 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
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>