OpsDir review of draft-zimmermann-avt-zrtp-17

[<[e-mail]>]

I have performed an Operations Directorate review of
  draft-zimmermann-avt-zrtp-17

Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones.  Improving the documents is important, but clearly a secondary purpose.  A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF.

Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document
requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents.

--------------

This draft specifies a proposed protocol for keying SRTP.  It is being published as an Informational RFC because the IETF chose a different proposal (draft-ietf-avt-dtls-srtp) to publish as Proposed Standard.  If this draft had been proposed for standards track publication, I would have characterized the automated system concern and the inability to backup secrets as open issues that merited discussion in the draft - both are tagged with [*].  As this draft will be published as informational, a lower standard of review may apply, and I leave it to the authors' judgment as to what changes should be made.

The operational aspects of the protocol are reasonably good - the protocol goes to a significant effort to avoid having to pre-provision and maintain authentication material by using an ephemeral DH exchange that is run from scratch on the first call between a pair of participants.  The protocol also adapts an SSH-like "leap of faith" model to protect subsequent interactions among the same parties.  By itself, an unauthenticated DH exchange can easily be subverted by a man-in-the-middle (MiTM) attack - the protocol defends against this by generating an identification of the protocol run (SAS) at each end that can then be compared by the participants reading the SAS to each other.  A successful MiTM attack will cause different SAS identifiers to be generated at the two call endpoints.

[*] The draft asserts that it is very difficult for an MiTM attacker to change the SAS on the fly in audio.  There is an obvious exception to this difficulty - if one of the parties on the call is an automated system, its voice response reading the secret is likely to have a predictable structure, and its vocalizations are likely to be easily recordable and/or otherwise forgeable by an MiTM.  This should be noted in the security considerations section after the paragraph on voice spoofing at the bottom of p.99, with a strong recommendation that credentials be provisioned at the automated system sufficient to use either the 7.2 signature technique or 8.1.1 integrity protection technique, and that those techniques always be used with pre-recorded or synthesized voice.

If the first call between two parties does not include voice confirmation of the SAS that instance of the protocol is MiTM-able.  The Introduction glosses over this by using the phrases "reasonable authentication against a MiTM attack" and "key continuity properties analogous to SSH".  While I believe both phrases are correct, the Introduction should also point out that the first call with no prior shared key material is MiTM-able, as is the case for SSH, as not every reader of this draft can be expected to be familiar with that aspect of SSH security.

[*] Unlike SSH, ZRTP updates the shared secret used to block MiTM attacks on every call.  This makes it impossible to backup and restore that secret because the backup becomes invalid on next use of the secret.  If a phone has to be hard reset (not unheard-of), it loses all of its secrets unless a backup is conducted immediately prior to the hard reset (not always possible as the failure requiring a hard reset may block backup).  This should to be pointed out as a counterpoint in the Security Considerations discussion of the requirements for protecting long-lived non-updated shared secrets, as used by SSH.

This ongoing shared secret update may increase the protocol's practical vulnerability to MiTM attacks because the participants cannot distinguish presence of an MiTM attacker from one party having lost its secret (or even the most recent update to the secret - a soft reset of the phone at exactly the wrong moment may cause this).  If the parties assume that the most common reason for setup failure is that a secret has been lost, an MiTM attacker inserts can mimic that by inserting herself in a call, thereby causing both sides to believe that the secret has been lost.  She then attacks the resulting initial run of the protocol - if voice confirmation of the secret is not used on that run, the attack succeeds.  Because this attack can be run at the time of the attacker's choosing, it is absolutely essential that the SAS's be confirmed by voice in this situation.  This is well described in the body of the draft, with appropriate use of MUST, but the following text in the Security Considerations section is too weak (IMHO), even though it uses the word "must":

   The user agent that discovers the cache mismatch must alert the user
   that a cache mismatch has been detected, and that he must do a verbal
   comparison of the SAS to distinguish if the mismatch is because of a
   MiTM attack or because of the other party losing her cache. 

I would like to see a discussion of this attack added to punctuate a direct warning that voice confirmation is essential in this situation.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------