[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt


Hi Richard,

Thanks for the question - it is a very good one.
Let me first address your comment that ZRTP is becoming similar to DTLS-SRTP. There are a number of important differences that remain:
1. Key continuity. The retained shared secrets in ZRTP allow media path authentication which does not suffer from problems of signaling response delay and lack of end-to-end integrity protection. It is interesting to note that DTLS-SRTP has introduced a similar concept in section 8.5. However, their proposed approach does not work unless a user is able to synchronize certificates across multiple SIP endpoints - otherwise, normal forking will cause authentication failures.
2. Short Authentication String. Only ZRTP allows users to take authentication into their own hands and do the verification in a human-factors friendly way.
3. Best Effort SRTP. Only ZRTP supports best effort SRTP natively. DTLS-SRTP relies on the still being developed MMUSIC SDP extensions for this to work. ZRTP can be, and is being, deployed today as a result. 

In terms of the disadvantages you list:
1. Some of us think that fewer authentication options and mechanisms is actually an advantage. TLS currently supports a myriad of suites. If DTLS-SRTP is used for SIP, will endpoints have to support all these suites? Is this possible for embedded and mobile devices? If not, this will cause interoperability failures. Also, ZRTP can use certificates if the endpoints have them - they can be used to sign the SAS which is passed in the Confirm messages. ZRTP does not provide transport for certificates, however.
2. ZRTP uses standard crypto algorithms and Diffie-Hellman public key exchange which has been around forever. ZRTP is already gaining traction in the marketplace (see http://www.zfoneproject.com/partners.html). Because it natively supports best effort SRTP, it is deployable today, unlike DTLS-SRTP. There are already multiple interoperable ZRTP implementations, and more are being developed as we speak, so I think we are quickly gaining implementation experience with the protocol. 

Thanks,
Alan

Richard Barnes wrote:

Alan,
Thanks for the update on your new draft. If I may ask a naive question: The net result of a lot of these changes seem to be making ZRTP very similar to DTLS-SRTP, with the disadvantages that 
(1) it has fewer authentication mechanisms (lacking certificates),
(2) it doesn't benefit from the prior implementations that DTLS does.

What do you perceive as the benefits of ZRTP vis a vis DTLS-SRTP?

Thanks,
--Richard



Alan Johnston wrote:


All,

There is a new version of ZRTP available.  Some major changes include:

- New title: ZRTP: Media Path Key Agreement for Secure RTP
- A new packet format. ZRTP now no longer uses RTP for transport. Instead, it is a distinct protocol multiplexed on the same port as RTP. The packet format is a similar structure to STUN, making it clearly distinguishable from both RTP and STUN.
- Discussion of how ZRTP meets all ten requirements in draft-wing-media-security-requirements-00.
- Changed "a=zrtp" SDP attribute to "a=zrtp-zid" which allows transport of ZID passed in ZRTP Hello message in the signaling for coupling of media and signaling paths. Combined contents of old "a=zrtp-sasvalue" into new "a=zrtp-sas" attribute.
- Changed Multistream mode to Preshared mode for a key agreement mode which does not require a DH calculation.
- New method of calculating the SAS that protects against both MiTM and bid-down attacks.
- New signature block allowing endpoints to sign the SAS and exchange signatures in the Confirm messages.
- Definition of a new ZRTP RTP extension header field. No ZRTP data is passed - the presence of the flag in RTP packets just indicates support for the ZRTP protocol.
- Improved discussion about the behavior of media intermediaries in media path keying. 

Comments and suggestions are most welcome.

Thanks,
Alan

-------- Original Message --------
Subject:     I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
Date:     Wed, 07 Mar 2007 10:50:02 -0500
From:     Internet-Drafts@xxxxxxxx
Reply-To:     internet-drafts@xxxxxxxx
To:     i-d-announce@xxxxxxxx
A New Internet-Draft is available from the on-line Internet-Drafts directories. 


    Title        : ZRTP: Media Path Key Agreement for Secure RTP
    Author(s)    : P. Zimmermann, et al.
    Filename    : draft-zimmermann-avt-zrtp-03.txt
    Pages        : 53
    Date        : 2007-3-7
    This document defines ZRTP, a protocol for media path Diffie-Hellman
  exchange to agree on a session key and parameters for establishing
  Secure Real-time Transport Protocol (SRTP) sessions.  The ZRTP
  protocol is media path keying because it is multiplexed on the same
  port as RTP and does not require support in the signaling protocol.
  ZRTP does not assume a Public Key Infrastructure (PKI) infrastructure
  or require the complexity of certificates in end devices.  For the
  media session, ZRTP provides confidentiality, protection against Man
  in the Middle (MITM) attacks, and, in cases where a secret is
  available from the signaling protocol, authentication.  ZRTP can
  utilize two Session Description Protocol (SDP) attributes to provide
  discovery and authentication through the signaling channel.  To
  provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-03.txt
To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zimmermann-avt-zrtp-03.txt". 

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 

Internet-Drafts can also be obtained by e-mail.

Send a message to:
    mailserv@xxxxxxxxx
In the body type:
    "FILE /internet-drafts/draft-zimmermann-avt-zrtp-03.txt".
    NOTE:    The mail server at ietf.org can return the document in
    MIME-encoded form by using the "mpack" utility.  To use this
    feature, insert the command "ENCODING mime" before the "FILE"
    command.  To decode the response(s), you will need "munpack" or
    a MIME-compliant mail reader.  Different MIME-compliant mail readers
    exhibit different behavior, especially when dealing with
    "multipart" MIME messages (i.e. documents which have been split
    up into multiple messages), so check your local documentation on
    how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.