On 4/24/2010 2:11 PM, Philip Zimmermann wrote:
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.
ZRTP uses a variant of a key rotation practice we designed as a part of
my "Blunt Tunneling" service which renegotiates a key session
dynamically within the context of the service after the well known key
exchange is used to open the connection.
Todd
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 Sec
ur
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
tglassey.vcf
Description: Vcard
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf