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
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf