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

From: David McGrew <[email-masked]>
Date: Fri, 10 Mar 2006 15:02:49 -0800

Alan, Phil,

I have a lot of comments and questions your new draft.

First, I believe that I've found a significant but correctable flaw in
the protocol.  In addition to the voice authentication procedure, if
the "retained shared secrets" rs1, rs2, or the secrets sigs, srtps,
and other_secret are present, then those secrets are used to
authenticate the DH exchange.  These secrets are intended to provide
security against the "Rich Little" attack, and to force an adversary
who does act as a MITM to do so during each and every conversation in
order to avoid detection.  However, even when these secrets are
present, they have no value if an adversary can fool the two sides
into thinking that no common shared secrets are present.  It appears
that an adversary can do this by replacing the values of rs1IDi,
rs2IDi, sigsIDi, srtpsIDi, and other_secretIDi with random values of
equal lengths, whenever those fields are present in the DHPart2
message, or by making equivalent substitutions tin the DHPart2
message.  If there is some mechanism in the protocol that prevents
this attack from working, I don't see what it is.  This would be a
significant flaw, because if an active adversary can defeat the
security services provided by those shared secrets, there would be no
point in including them in the protocol.

I think that this problem can be solved by including the values of
rs1IDi, rs2IDi, sigsIDi, srtpsIDi, and other_secretIDi in the inputs
to the "hash" in the Commit message.  But the rs1IDr, rs2IDr,
sigsIDr, srtpsIDr, and other_secretIDr values would need to be committed
to by providing them in some other hash generated by the responder.
This hash would need to be added to the protocol.

Below I've provided a lot of detailed comments and questions on the
specification, itemized for easier discussion.

Best regards,

David

--

1.  ZRTP can provide authentication on the DH exchange if the
     signaling layer provides the two endpoints with a shared secrets.
     It would be greatly preferable if, instead, ZRTP could provide
     session authentication relying only on the signaling channel to be
     authenticated (and not to provide confidentiality).  This is
     because for SIP, it is much easier to provide asymmetric
     authentication (e.g. with SIP Identity) than confidentiality.  (As
     is always the case with public key cryptography, given the
     differences between signatures and encryption.)  Why not just send
     a hash value of the public key values through the signaling
     channel?  Perhaps this is out of consideration because it is a
     goal for ZRTP to work even with signaling systems that are not
     aware of ZRTP.  Nevertheless, in order for ZRTP to offer more
     value when signaling systems are aware of it, I suggest that the
     hash of the public keys be sent through the signaling channel, at
     least as an option.   This is what's done in [1].

2.  Do the DH and key derivation functions conform to the NIST
     specification [2]?  (At least the KDF appears not to.)  If not,
     why not?

3.  Abstract.  The word "infrastructure" is unintentionally repeated.

4.  Abstract.  It might be better to clarify the security services
     provided on the session establishment from those provided on the
     media (presumably ZRTP can provide all of the security services
     that SRTP can provide - "confidentiality, message authentication,
     and replay protection to the RTP traffic and to the control
     traffic for RTP, the Real-time Transport Control Protocol
     (RTCP)".)

5.  Introduction.  ZRTP is point-to-point, though RTP is not.  This
     should be explicitly mentioned (e.g.  how does a device behave
     when there are multiple other session participants).

6.  Ephemeral DH is used - but is it permissible to cache a DH key pair
     and use it in multiple sessions?  I think not, since no nonces are
     present.  Since the use of a single DH public key across multiple
     sessions would nearly double the performance, why not admit
     this optimization in the protocol?

7.  Where it says "... caching shared secrets seemed a bit simpler,
     and has the added benefit of adding more entropy to the session
     keys.", I suggest replacing "adding more entropy" with "making the
     keys less predictable to an adversary".

8.  Section 3.1.  Why is AVP/RTP negotiated instead of AVT/SRTP?  If a
     signaling system intends to protect the media session, shouldn't
     it tell the other side?  There are system implications due to the
     use of SRTP, such as the increased bandwidth usage due to packet
     expansion, and the increased CPU usage.  For example, some DSPs
     can only perform SRTP with certain codecs.

9.  ZRTP would only work with Symmetric RTP [3] if both sides sent
     Hello messages.  Is this the case?  Symmetric RTP is commonly used
     in order to allow RTP sessions to traverse NAT and firewall
     devices.  This facility relies on the fact that the media source
     behind the NAT sends data that triggers a NAT translation that
     allows inbound media.  If the initiator of the ZRTP handshake is
     outside of the NAT or firewall, then ZRTP will fail.

10.  There are some RTP application dependencies in ZRTP - "silence,
      no-op, comfort noise" payloads are needed.  This is a layer
      violation between the RTP application and ZRTP.  It would be much
      better to make ZRTP completely independent of the application, if
      that's possible.  One way to do this would be to define ZRTP as a
      use of SRTP (or as a separate RTP profile), in which zero-length
      payloads are sent until an SRTP master key is established.

      Another consideration is the RTCP traffic - presumably no
      plaintext RTCP traffic would be sent out if the SRTP crypto
      policy was to provide confidentiality on RTCP.

11.  The spec refers in 3.2.2 to "the AES key length".  Ideally, the
      spec should not refer to AES specifically at this point for the
      sake of algorithm agility.  (Of course, AES is a good algorithm
      to use.)

12.  "Responder" - does this string include the terminating NULL?

13.  Section 3.2.2.  A nit - "ascending numerical order" is not
      defined for byte strings - treat as uint64_t value in network
      byte order?

14.  Section 3.2.4.  The SRTP key derivation rate (KDR) should be
      zero, not 2^48.  Zero means "no key derivation other than the
      original one", while 2^48 would mean "rekey for every packet".

15.  Section 3.2.4.  The SRTP AES Counter Mode cipher isn't defined
      for AES-256.  As we've discussed, there is certainly enough
      interest in the community to define and standardize it.  This
      obviously ought to be done in its own draft.

      The complexity with larger key sizes is that a different key
      derivation function will need to be defined for use with AES-256
      in SRTP.  This is not a big deal, because SRTP is intentionally
      modular with respect to the KDF.  I suggest that we adopt the
      standard practice of using a crypto-suite in which the KDF and
      the encryption method are 'bound' together.

16.  Section 4.  ZRTP's use of the RTP header extension renders it
      unusable with RTP stacks that use their own header extensions.
      During the development of SRTP, the AVT WG was clear that they
      desired SRTP to not use the RTP header extension for this reason.

      ZRTP can probably sidestep this issue as follows: it can define a
      header extension format that can optionally incorporate a second
      header extension, like this:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|      defined by ZPHONE      |           length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   ZPHONE header extension                     |
    |                             ....                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Secondary header extension                  |
    |    If F = 1, this field contains a second header extension    |
    |                If F = 0, this field is empty                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      When ZRTP processing is applied to an RTP packet, if a header
      extension is present, then it is copied into the "secondary
      header extension" field, and F is set to 1.  Otherwise, F is set
      to 0.

17.  Section 4.1. "..  extended with spaces (0x20) to make them 8
      characters long."  "Padded" is probably a better word than
      "extended" here.

18.  Section 7.  IANA considerations.  The "a=zrtp" SDP attribute from
      Section 10 needs to be registered, doesn't it?

References

   [1]  M. Baugher, D. McGrew, Diffie-Hellman Exchanges for Multimedia
        Sessions, draft-baugher-mmusic-sdp-dh-00.txt

   [2] NIST Daft Special Publication 800-56, Recommendation for Pair- 
Wise
       Key Establishment Schemes Using Discrete Logarithm Cryptography

   [3] Wing, D., Common Local Transmit and Receive Ports (Symmetric
        RTP) draft-wing-behave-symmetric-rtprtcp-01

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

---

From: Philip Zimmermann <[email-masked]>
Date: Sun, 19 Mar 2006 21:58:59 -0800

David,

Thanks for your detailed review - see our comments below.

Phil.

> This hash would need to be added to the protocol.

While it may not be currently detailed in the draft, an endpoint that
discovers that expected shared secrets are apparently not shared will
share this information with the user.  While there may be valid reasons
for this (re-installation of software, disk crash, etc.) in most cases,
this error condition can be interpreted as a possible attack.  This can
then be used to prompt the user to utilize the SAS authentication.

Also, a future version of the draft will detail the difficulties of the
"Rich Little" attack and show that while it is possible on paper, it
would be almost impossible to succeed against humans, with their
ten-trillion-operations-per-second brains acting as discriminators.

> specification, itemized for easier discussion.

You are saying that by making Alice and Bob believe they do not have  
any cached shared secrets, you can force them into a position where  
you can mount a Rich Little attack.  But we deny that a Rich Little  
attack has a realistic chance of success with normal human participants.

>     specification [2]?  (At least the KDF appears not to.)  If not,

I have just reviewed the NIST specification and I like it.  I will  
study this further and see what would be appropriate to include.   
Thanks for bringing that up.

> 3.  Abstract.  The word "infrastructure" is unintentionally repeated.
Will fix.

>     (R

> TCP)".)
Will add.

>     when there are multiple other session participants).
Agreed.  ZRTP does not work with multicast sessions.

>     this optimization in the protocol?

No - I don't think this a good idea.  However, we are considering a  
related
optimization that would allow multiple simultaneous media streams
between two endpoints to use the same shared secret.  Currently, if a
video and audio stream are established, each is treated independently by
ZRTP and would have a separate DH exchange.

>     keys

> less predictable to an adversary".
>

OK

>     can only perform SRTP with certain codecs.

A key design requirement of ZRTP is that it have no dependencies on the
signaling layer.  This enables ZRTP to work even when different
signaling protocols are in use as in through a gateway (e.g. SIP and
H.323 or SIP and Jingle).  Also, ZRTP avoids the backwards compatibility
problem implementors are faced with today.  To use signaling-based
SRTP setup today, a UA must use a multipart/alternative message body
containing two SDP offers - one with AVT/SRTP and the other with
AVT/RTP.  The handling of multipart/alternative in older SIP UAs is just
appalling - and generally produces a large numbers of failures and even
crashes.  The only other alternative is to send an INVITE with AVT/SRTP
first, then if it fails, resend the INVITE with AVT/RTP.  Both of these
alternatives are awful and implementors hate them.

>     outside of the NAT or firewall, then ZRTP will fail.

As Jonathan has pointed out with regards to RTP over DTLS, this is an
orthogonal issue.  ZRTP works just fine after ICE has been used, thus
providing this symmetric operation and opening pin-holes and creating
NAT bindings.

>      policy was to provide confidentiality on RTCP.

Again, ZRTP starts with RTP and attempts to convert the session to
SRTP.  It doesn't make sense and would  be detrimental to make ZRTP an
extenison to SRTP or require a separate profile.

>      sake of algorithm agility.  (Of course, AES is a good algorithm

Sure - we'll fix this.

> 12.  "Responder" - does this string include the terminating NULL?

That is a good question.  The answer is that these strings (and others
in the draft) do not include the terminating NULL - we will clarify  
this.

>      defined for byte strings - treat as uint64_t value in network

We will clarify.

>      original one", while 2^48 would mean "rekey for every packet".

Right - we certainly do not want to rekey for every packet ;-)  We  
meant to say the master key lifetime should be 2^48, or infinity and  
beyond!

>      obviously ought to be done in its own draft.

The AES-256 version of the KDF was so self-evident that I didn't  
think of explicitly defining it.  The AES-256 version of the KDF is  
keyed with a 256-bit master key, and we just drive the KDF to output  
the two AES keys so that they are 256 bits long, while leaving all  
the other outputs the same length.  Perhaps you should write up an  
extension to RFC 3711 to include that.

>      header extension, like this:

This is a good suggestion.  However, in general ZRTP will generate its
own no-op packets rather than piggy back on RTP packets containing other
information which may also contain a header field extension.  It is
worth clarifying that ZRTP would simply encapsulate any existing header
extensions and carry them unchanged.

>      characters long."  "Padded" is probably a better word than

OK

>      Section 10 needs to be registered, doesn't it?

Yes - this new SDP attribute will need to be defined in an MMUSIC draft
and registered with IANA.

>   [2] NIST Draft Special Publication 800-56, Recommendation for  
> Pair- Wise

---

From: Philip Zimmermann <[email-masked]>
Date: Tue, 21 Mar 2006 08:29:32 -0800

David, you are saying that by making Alice and Bob believe they do  
not have any cached shared secrets, you can force them into a  
position where you can mount a Rich Little attack.

At first glance I thought your attack was not worth fixing because of  
the infeasibility of the Rich Little attack.  Upon further  
reflection, I think we went to some effort to form these retained  
shared secrets, and it seems wrong to let the attacker get away with  
denying us access to them without detection, regardless of the  
infeasibility of the Rich Little attack.  Besides, some users will  
not bother to check the SAS.  So we should change the protocol.

The hash commit packet should include the entire DH packet in the  
hash calculation, not just the g^x portion of that packet.  This will  
prevent the attacker from tampering with the shared secret HMACs to  
fool us into thinking we don't share any secrets.  Of course, the  
rest of the material that was included before in the hash commit  
calculation should still be included.

Thanks, David, for pointing out the importance of this problem.  It  
has helped to improve the protocol.

-Phil

>> specification, itemized for easier discussion.

----------------------------------------------
Philip R Zimmermann        [email-masked]
http://philzimmermann.com  tel +1 650 322-7223
(spelled with 2 n's)       fax +1 650 322-7877

---

From: Randell Jesup <[email-masked]>
Date: Fri, 24 Mar 2006 10:55:20 -0500

Philip Zimmermann <[email-masked]> writes:
>No - I don't think this a good idea.  However, we are considering a  related

This (deriving the keys for multiple streams in a session) would be a big
win, given the cost of DH.  Also, when doing this please consider the issue
of reinvite within a session (to add, remove, or modify codecs/streams).

>alternatives are awful and implementors hate them.

Those are all issues, for sure - but you're advocating that "because old
implementations suck, lets hide what we're doing".  Hiding it will cause
pain for more-complex proxies, endpoints and transit channels.  As pointed
out, a proxy seeing a known codec with AVT/RTP will assume it knows the
size of the payloads, that it can decode them, that it can mix them with
other data, etc.  For example, what if a provider using SBCs provided the
equivalent to "operator break-in" for emergencies?  If they did it by
noticing "hey, they're G711 with AVT/RTP, I can just mix my audio into the
session" it would a) not work, and b) totally garble the session.  Or if
you started a two-person conference via an MCU (acting as a transparent
proxy), and then the MCU wanted to insert an announcement or mix a new
addition to the conference in?

The problems with multipart vs reinvite vs grouping, etc are real - but
this doesn't really help the problem.  I understand the need to
interoperate, and that spoofing AVT/RTP may be needed in some (many) cases
for now, but I don't like locking that in and simply giving up on having
AVT/blah ever mean anything or being able to negotiate crypto/transport
protocols.

>providing this symmetric operation and opening pin-holes and creating

Are you saying that ZRTP requires ICE (or equivalent) in this case?
That's a significant loss of functionality.

>extensions and carry them unchanged.

Does "in general" mean "always"?  And if so, are there any implications of
this?  If it is "always", that should be specified.  If it's not "always",
then you have to at least decide how header extentions will be dealt with.
And other protocol levels/gateways/etc may insist on having an RTP header
extension on every packet in a stream, or so I could imagine.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]