ietf
[Top] [All Lists]

Re: I-D Action:draft-zimmermann-avt-zrtp-20.txt

2010-05-14 04:35:07
On 11 May 2010, at 22:15, Internet-Drafts(_at_)ietf(_dot_)org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : ZRTP: Media Path Key Agreement for Unicast Secure RTP
        Author(s)       : P. Zimmermann, et al.
        Filename        : draft-zimmermann-avt-zrtp-20.txt
        Pages           : 111
        Date            : 2010-05-11

This document defines ZRTP, a protocol for media path Diffie-Hellman
exchange to agree on a session key and parameters for establishing
unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP
applications.  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) 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 the signaling protocol provides end-to-end integrity
protection, authentication.  ZRTP can utilize a Session Description
Protocol (SDP) attribute to provide discovery and authentication
through the signaling channel.  To provide best effort SRTP, ZRTP
utilizes normal RTP/AVP profiles.  ZRTP secures media sessions which
include a voice media stream, and can also secure media sessions
which do not include voice by using an optional digital signature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-20.txt


This addresses some, but not all, of my comments on -17:

- “In terms of the RTP topologies defined in [RFC5117], ZRTP is designed for Point to Point topologies only” - if only Topo-Point-to- Point is supported, explicitly state that by shortcut name, otherwise also list the other topologies that are supported by shortcut name.

- “Other [RTP] profiles MAY also be used” - which ones? Need to be explicit, since not all conceivable RTP profiles would work with ZRTP.

- This version states that “SSRC collisions would be disruptive to ZRTP. This may be avoided via the mechanisms in RFC 3550, Section 8.2 [RFC3550]”. The mechanisms in section 8.2 of RFC 3550 explain how to resolve SSRC collisions, not how to avoid them, and say nothing about how to avoid disruption to ZRTP. Further clarification is needed - I’d guess that the right thing to do is to accept that SRRC collisions are disruptive, and force a re-negotiation of the secure session. If so, the draft needs to state this explicitly.

- A ZRTP Error code of 0x91 “SSRC collision” is defined, but the text doesn’t mention how it’s used.

- The new discussion of timers for non-UDP transports in section 6 is much improved, but could still do with giving explicit recommendations for the lengthened timer intervals.

- The new text regarding the ZRTP header extension is better, but could still do with explicitly stating that not only does ZRTP not use the RFC 5285 mechanisms, it conflicts with them.

--
Colin Perkins
http://csperkins.org/



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: I-D Action:draft-zimmermann-avt-zrtp-20.txt, Colin Perkins <=