David, thank you for reviewing our draft. Your suggestions were helpful.
It was a pleasure talking with you on the phone. I'm glad we had a chance to
discuss the points you raised.
We addressed all the issues you raised in the next draft, draft 18.
Regards,
Phil
On Mar 29, 2010, at 6:43 PM, <Black_David(_at_)emc(_dot_)com>
<Black_David(_at_)emc(_dot_)com> wrote:
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 Secur
ity 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
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
------------------------------------------------
Philip R Zimmermann prz(_at_)mit(_dot_)edu
(spelled with 2 n's) http://philzimmermann.com
tel +1 831 425-7524 http://zfone.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf