Subject: RE: [AVT] draft-zimmermann-avt-zrtp-00.txt

From: "Even, Roni" <[email-masked]>
Date: Tue, 28 Feb 2006 16:54:13 +0200

Hi Alan,
Thanks, 
I am still not clear about when encryption starts. Figure 1 shows SRTP
before the confirm message.

The following text in section 3.2.4 with figure 1

"The endpoints can now switch to SRTP and begin packet encryption. The
ZRTP Initiator and Responder use their own keying material for the SRTP
session.  No MKI is used and a 32 bit authentication tag is used."

Both hints that you can start encryption right after the DHpart1 and
DHpart2 messages. And so it got me wondering about synchronization.

If the idea is for each side to send a confirm message as the first
encrypted packet this should be stated and it will work if the packet is
not lost. 
If you meant that only after receiving confirmack you can start
encryption then there is still a synchronization problem. 

Roni

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2006 4:26 PM
To: Even, Roni
Cc: [email-masked]; Philip Zimmermann
Subject: Re: [AVT] draft-zimmermann-avt-zrtp-00.txt

Hi Roni,

Thanks for your comments - see mine below.

Thanks,
Alan

Even, Roni wrote:

>Hi,
>I read the draft and find it interesting I have some questions.
>
>1. The key exchange is done after the RTP connection is established,
>this means that until the end of key exchange both sides will send
>non-encrypted information. 
>
Correct.

>I think that the document should address the
>issue. One way is to recommend using no-op packets until the system
will
>start to encrypt and indicating this to the user.
>  
>
This is an excellent idea to use no-op packets.  The Zfone 
implementation uses a GUI and tones to indicate the status of the call 
to the user (insecure, securing, or secure).

>2. It is not clear to me how does the receiver know which is the first
>packet that is encrypted.
>
>  
>
The first packet that is encrypted is the Confirm1 message.  It has a 
known plain text string in the SRTP payload so that the endpoint can 
verify that decryption has been successful.  The other side then sends a

Confirm2 message to confirm the encryption on the other side.  After the

Conf2ACK, the key agreement is over and normal SRTP packets with media 
can then be exchanged.

>3. In section 10 you have "If both UAs support ZRTP, they will first
try
>ZRTP before attempting SRTP". I assume that it means that even though
>the sides already have a shared secret they should not start SRTP and
do
>ZRTP exchange first.
Correct.

> What is the reason for that. Based on my first
>comment it will make sense to start SRTP when starting to send media
and
>maybe use re-key based on ZRTP.
>  
>
We were trying to avoid doing a double encryption, where the media was 
first encrypted as SRTP using a master key and salt from the signaling, 
then encrypting again with ZRTP using DH.  Instead, it would be better 
to exchange a master key and salt in the signaling, then mix this secret

in with the DH shared secret.  If for some reason, ZRTP fails, then the 
two UAs should do SRTP using the exchanged master keys and salt.

>4. In section 3.1 "If none of these are supported, an RTP packet
>containing
>   comfort noise can be generated to carry a ZRTP message." I
understand
>that ZRTP is not only for audio so comfort noise is not a video or
>application payload. The common mode is no-op which was defined to all
>media types.
>
>  
>
Yes - we had forgotten about the no-op - it is the correct choice.

>Thank
>Roni Even 
>
>-----Original Message-----
>From: Alan Johnston [mailto:[email-masked]] 
>Sent: Monday, February 27, 2006 3:57 PM
>To: [email-masked]
>Cc: Philip Zimmermann
>Subject: [AVT] draft-zimmermann-avt-zrtp-00.txt
>
>All,
>
>We have just submitted a new Internet-Draft 
>draft-zimmermann-avt-zrtp-00.txt.  Until it becomes available in the 
>archives, you can get a copy at:
>
>   http://www.philzimmermann.com/zfone/draft-zimmermann-avt-zrtp-00.txt
>
http://www.philzimmermann.com/zfone/draft-zimmermann-avt-zrtp-00.html
>
>We will request a slot in AVT in Dallas to discuss.  Discussion about 
>the RTP extensions and mechanism are best held on the AVT list while 
>discussions about key management for SRTP are best held on the MMUSIC 
>list, with some cross posting as needed.
>
>Thanks,
>Alan
>
>- - -
>
>ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP
>                   draft-zimmermann-avt-zrtp-00
>
>Abstract
>
>This document defines ZRTP, RTP (Real-time Transport Protocol) header
>extensions for a Diffie-Hellman exchange to agree on a session key
>and parameters for establishing Secure RTP (SRTP) sessions.  The ZRTP
>protocol is completely self-contained in RTP and does not require
>support in the signaling protocol or assume a Public Key
>Infrastructure (PKI) infrastructure.  For the media session, ZRTP
>provides confidentiality and, in cases where a secret is available
>from the signaling protocol, authentication.
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt
>
>
>  
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Alan Johnston <[email-masked]>
Date: Tue, 28 Feb 2006 21:51:55 -0600

Hi Roni,

Yes, this does need clarification in the draft.  Each side may start 
sending SRTP packets with media after they send their Confirm messages.  
So, after the responder sends the Confirm1, the responder can send 
SRTP.  After the initiator sends the Confirm2, the initiator can send 
SRTP.  We'll move the "SRTP begins" in Figure 1 to after the Confirm 
messages.

Thanks,
Alan