David,
Thanks for your detailed review - see our comments below.
Phil.
David McGrew wrote:
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.
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.