Subject: [AVT] (no subject)

From: "David A. McGrew" <[email-masked]>
Date: Tue, 21 Mar 2006 04:29:04 -0800

Hi Phil,

> 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.

as we'd discussed yesterday, it would be greatly preferable for the  
protocol to detect this condition, rather than to rely on human  
interaction.  Fortunately it's not too hard for the protocol to  
achieve that property, using commitments or other hash or MAC checks  
like we'd talked about.

For others that are interested, I dug out my old protocol design  
document that discusses this security issue and put it online at  
http://www.mindspring.com/~dmcgrew/spdp.txt.  It uses a method of  
detecting shared secrets that is similar to that in ZRTP, and Section  
3 discusses countermeasures.

David

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt