Re: [AVT] Last Call: draft-zimmermann-avt-zrtp (ZRTP: Media Path Key Agreement for Secure RTP) to Informational RFC

[Alan Johnston <[e-mail]>]

Colin,

Thank you for your detailed review of the draft.  See my comments below.

- Alan -

On 4/13/10 12:19 PM, Colin Perkins wrote:
> On 17 Mar 2010, at 22:26, The IESG wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>>
>> - 'ZRTP: Media Path Key Agreement for Secure RTP '
>>   <draft-zimmermann-avt-zrtp-17.txt> as an Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to the
>> [e-mail] mailing lists by 2010-04-14. Exceptionally,
>> comments may be sent to [e-mail] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
> 
> 
> I've reviewed this draft, and have a number of comments. The main issue
> is the scope of the protocol: it claims to be "Media Path Key Agreement
> for Secure RTP", but may be better titled "Media Path Key Agreement for
> Unicast Voice Telephony Using Secure RTP". The majority of RTP sessions
> cannot be secured using ZRTP, but this draft is virtually silent on its
> limitations. 

The draft does point out that it is for securing unicast RTP only.  For
example, in Section 1:

"ZRTP is designed for unicast media sessions in which there is a voice
media stream."

Including unicast in the title does seem to be a reasonable thing to do
and we will do that.

However, scoping it to voice telephony is not accurate.  While the Short
Authentication String is the preferred security mechanism, the protocol
also works with digital signatures and can be authenticated using an
integrity protected signaling channel. Neither of these methods require
a voice channel.

Some details follow:
> 
> - RTP is explicitly a group communication protocol, that supports a wide
> range of topologies [RFC 5117], and a wide range of media types. ZRTP is
> defined for point-to-point audio calls or group audio conferences with a
> centralised conference bridge, and doesn't support the full range of RTP
> topologies or media formats. This is probably an acceptable limitation,
> but needs to be much more clearly documented than in the present draft.

We propose adding unicast to the title and having this as the first
sentence of the Abstract:

"  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 draft claims it works with the RTP/AVP profile (although this is
> misspelt AVP/RTP in section 3). This is only one of several RTP profiles
> that can be used, but nothing is said about the other RTP profiles, such
> as RTP/AVPF. To avoid confusion, the draft should explicitly state which
> of the other RTP profiles are supported and which are not.

ZRTP uses the RTP/AVP profile in order to support best effort encryption
without any reliance on signaling protocol extensions or mechanisms.
However, there is no reason why it won't work with other RTP profiles.

We will add text indicating this.


> 
> - Section 5 uses the SSRC to associate ZRTP messages with an RTP stream,
> but doesn't appear to consider the possibility of an SSRC collision [RFC
> 3550 section 8.2].

Sure - we should mention that if a VoIP call is forked to two endpoints,
and media sessions are established with both, and they both choose the
same 32 bit SSRC, then ZRTP will not be able to distinguish between them.


> 
> - RTP can run over non-UDP transports, such as TCP and DCCP. Section 6
> of the draft defines retransmission timers for ZRTP that are reasonable
> for RTP/UDP/IP sessions, but not for RTP/TCP/IP or RTP/DCCP/IP sessions.
> The draft needs to discuss use of ZRTP over non-UDP transports.

If the media is transported end-to-end using a reliable transport, then
clearly ZRTP retransmissions are not needed.  However, there can be
cases involving relays where ZRTP could be sent over a reliable
transport part of the way, and an unreliable transport the rest of the
way.  We will add text recommending that if reliable transport is used,
then the retransmit timers should be lengthened.

> 
> - Section 7.3 discusses relaying ZRTP through a PBX. There appears to be
> an assumption that the PBX is configured to provide point to multipoint
> service as an RTCP-Terminating MCU (Topo-RTCP-terminating-MCU in the
> terminology of RFC 5117). None of the other topologies defined in RFC
> 5117 are considered.

I couldn't find where you got this idea from.  A PBX is not going to act
as an RTCP-Terminating MCU.  It will most likely act as a B2B for both
the signaling and media, but it will still be 1:1.  We can clarify this.
 ZRTP does not apply to all the topologies of RFC 5117.


> 
> - The draft does not specify how traffic RTCP is secured. This might be
> done using the key negotiated on the media path, or it might require a
> separate ZRTP negotiation using multistream mode, but the draft doesn't
> specify.

ZRTP doesn't define a new way to secure either RTP or RTCP - it just
provides a key agreement for SRTP.  RFC 3711 defines how to secure RTCP
given a master secret.  We should probably just state this.


> 
> - SDES is a commonly used abbreviation in the RTP community for RTCP
> Source Description packets, yet this draft uses it for other purposes.
> To avoid confusion, please expand the acronym (e.g., in Section 8.2).


Right - we'll call it "SDP Security Descriptions (SDES)" in the draft,
to avoid confusion between AVT and security readers.

> 
> - The recommendations in Section 8.3 to avoid VBR traffic with secure
> calls are at odds with the recent discussion in the AVT working group
> (IETF 76).

Is this discussion captured in draft-perkins-avt-srtp-vbr-audio?  We are
currently reading this draft.

> 
> - Section 10 assumes that the presence of an RTP mixer can be determined
> from the signalling. This assumption is false in general, although it's
> true for some SIP-initiated calls.

Right - in some cases being in a conference call can be deduced from the
signaling (using 'isfocus' in SIP for example) or in other cases, only
the human will know.  We will clarify the text.


> 
> - The RTP header extension for ZRTP (Section 12) conflicts with the
> mechanism defined in RFC 5285. At minimum, this conflict should be
> documented, and it might make sense to update this draft to use the RFC
> 5285 mechanism.
> 

We will add text referencing RFC 5285 and explaining the relation.
Basically, the ZRTP usage and deployment of RTP header extensions
predates this standard.  Also, this model of negotiating header
extensions in the signaling does not fit with ZRTP's signaling
indpendent design.