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

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

To: "'Tom-PT Taylor'" <taylor@xxxxxxxxxx>
Subject: RE: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
From: "Dan Wing" <dwing@xxxxxxxxx>
Date: Mon, 12 Mar 2007 10:41:55 -0700
Authentication-results: sj-dkim-5; header.From=dwing@xxxxxxxxx; dkim=pass (s ig from cisco.com/sjdkim5002 verified; );
Cc: "'Christer Holmberg \(JO/LMF\)'" <christer.holmberg@xxxxxxxxxxxx>, <ietf-rtpsec@xxxxxxx>
Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12031; t=1173721316; x=1174585316; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@xxxxxxxxx; z=From:=20=22Dan=20Wing=22=20<dwing@xxxxxxxxx> |Subject:=20RE=3A=20Fwd=3A=20I-D=20ACTION=3Adraft-zimmermann-avt-zrtp-03. txt |Sender:=20; bh=Hp6CRJFvhmrP8a8XX485VQIqfoUOb/B8sjntDiXVeEo=; b=qDJ58Y4Zj+eqkWG2sAaBnHXW/kcgKP/Ncoxv/E9bNZ0ZqeWhfCu4xtuhS57OjK6EAiVq8GQT payIEzVG2dBe96ZRkOl72woIT0M6+jKTPY8THX3ME6i0y3sjFQbWWMa3;
In-reply-to: <45F58D0F.9050801@xxxxxxxxxx>
List-archive: <http://www.imc.org/ietf-rtpsec/mail-archive/>
List-id: <ietf-rtpsec.imc.org>
List-unsubscribe: <mailto:ietf-rtpsec-request@imc.org?body=unsubscribe>
Sender: owner-ietf-rtpsec@xxxxxxxxxxxx
Thread-index: Acdky5x+sr/LsWinRhaxL2yFjN/E5AAAZAVw

But none of STUN, ZRTP, DTLS-SRTP, or MIKEYv2 are media packets -- they're
not RTP or SRTP packets.  It's only ZRTP's first packet that is an RTP media
packet, but that is only for its probing to support its best-effort SRTP; if
this is problematic on those networks where RTP is blocked, ZRTP could rely
entirely on being signaled (a=zrtp-zid) or perhaps also probe using its ZRTP
packets (which, like STUN and DTLS-SRTP and MIKEYv2, can be demultiplexed by
the receiver when they're sent over the same port as RTP or as RTCP).

-d


> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@xxxxxxxxxx] 
> Sent: Monday, March 12, 2007 10:26 AM
> To: Dan Wing
> Cc: Christer Holmberg (JO/LMF); ietf-rtpsec@xxxxxxx
> Subject: Re: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
> 
> There's that fundamental problem: if you allow two-way media 
> flow before billing 
> starts, you may never get anything to bill. So it's possible 
> we do have to think 
> of this as a requirement.
> 
> Dan Wing wrote:
> ...
> > 
> >> Another thing to remember is that the signalling path is normally 
> >> "two-way" from the start, while the media plane path may only be 
> >> one-way (enforced using gates etc) during the session setup, which 
> >> means that mechanisms realying on terminals performing two-way 
> >> negotiation on the media plane may not work (at least not 
> >> until INVITE 200 OK has been sent).
> > 
> > Operating with those systems is not a requirement gathered in
> > draft-wing-media-security-requirements.  Should it have been?
> > 
> > Note that those systems won't work with ICE, either.
> > 
> > What do you advise we do -- change those get those systems changed 
> > or give up and key entirely in SIP?  There was consensus in 
> > Montreal that we can't achieve success with an entirely call-
> > signaling-based approach.  I don't see how we could revisit that
> > now, a week before the Prague IETF.
> > 
> > -d
> > 
> > 
> >> Regards,
> >>  
> >> Christer
> >>
> >>  
> >>
> >>> -----Original Message-----
> >>> From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> >>> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of Dan Wing
> >>> Sent: 11. maaliskuuta 2007 21:18
> >>> To: 'Alan Johnston'; 'Richard Barnes'
> >>> Cc: ietf-rtpsec@xxxxxxx; 'Philip Zimmermann'; 'Jon Callas'
> >>> Subject: RE: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
> >>>
> >>>
> >>>
> >>> Alan Johnston wrote:
> >>>> Richard Barnes wrote:
> >>>>> In addition, since there's no information from signaling 
> >>> necessary 
> >>>>> to initiate a ZRTP key negotiation, once I've sent an 
> >> offer, ZRTP 
> >>>>> would have me perform a key exchange with any host on the 
> >>> Internet 
> >>>>> that asked for one.  In other words, ZRTP creates a 
> >>>>> denial-of-service opportunity that's available to any 
> >> host on the 
> >>>>> Internet, not just those on the signaling path.
> >>>> The same is true for DTLS-SRTP - once you send the offer 
> >>> saying what 
> >>>> ports you are listening on, you have to process anything 
> >>> that comes in 
> >>>> on that port.  It may be up to 30 seconds before you get an 
> >>>> authenticated signaling message - any host can either 
> send a ZRTP 
> >>>> Hello or a DTLS ClientHello.
> >>> (I think I didn't reply to this point earlier.)
> >>>
> >>> Both ZRTP and DTLS-SRTP can protect against that attack if 
> >>> the offerer waits for the SDP answer and uses the a=zrtp-zid 
> >>> (for ZRTP) or a=fingerprint (for DTLS-SRTP) to ensure the 
> >>> ZRTP or DTLS-SRTP exchange is with an endpoint that was 
> >>> signaled via call signaling.
> >>>
> >>> -d
> >>>
> >>>
> >>>> Thanks,
> >>>> Alan
> >>>>> Cheers,
> >>>>> --Richard
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> 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.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> > 
> >

References:
- Re: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
  - From: Tom-PT Taylor

Prev by Date: Re: draft-lehtovirta-rtpsec-infra-00
Next by Date: Re: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
Previous by thread: Re: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
Next by thread: RE: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt
Index(es):
- Date
- Thread