IETF Logo Mail Archive

Re: [rtcweb] Consent freshness and message-integrity (Re: Use Case draft - legacy interop)

Harald Alvestrand <harald@alvestrand.no> Mon, 07 May 2012 21:46 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BB021F870A for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 14:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.524
X-Spam-Level:
X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVj6HmYh8+tV for <rtcweb@ietfa.amsl.com>; Mon, 7 May 2012 14:46:20 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1DD21F86F1 for <rtcweb@ietf.org>; Mon, 7 May 2012 14:46:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C61F839E1E2; Mon, 7 May 2012 23:46:19 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SITVyAoQygNK; Mon, 7 May 2012 23:46:18 +0200 (CEST)
Received: from [172.28.93.74] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A03EB39E107; Mon, 7 May 2012 23:46:18 +0200 (CEST)
Message-ID: <4FA842A8.7070104@alvestrand.no>
Date: Mon, 07 May 2012 23:46:16 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <CA+9kkMCYArLPRP3c00UdOja64WRT6ghN0PSy7XvM_wbxBBB+vA@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <E2714FBC-D06B-4A12-9E07-C49EBF55084C@phonefromhere.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <CAJNg7VKENERKAFA-n5KeoeBNmGgHrnzDOU0BzC9+fSdsuGwdEw@mail.gmail.com> <E17CAD772E76C742B645BD4DC602CD810616F24F@NAHALD.us.int.genesyslab.com> <4FA0F43E.4020308@ericsson.com> <E17CAD772E76C742B645BD4DC602CD810616F336@NAHALD.us.int.genesyslab.com> <4FA1575C.4050508@ericsson.com> <E17CAD772E76C742B645BD4DC602CD810616F4BF@NAHALD.us.int.genesyslab.com> <4FA37A1E.4080806@alvestrand.no> <CALiegf=H5QH_YY-cJ4z29wChWZ-VoQpHvsZCeaJPjTgVp+km3Q@mai l.gmail.com> <0db701cd 2adb$98082f10$c8188d30$@com> <CALiegf=C7a6zeUDHn-Wuku9eFWmADG5N+D8oXSQbwJKSYYjcQg@mail.gmail.com> <0dc901cd2ae3$f9ffb500$edff1f00$@com> <4FA83B3A.9070600@alvestr and.no> <027601cd2c97$b107e1a0$1317a4e0$@com>
In-Reply-To: <027601cd2c97$b107e1a0$1317a4e0$@com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consent freshness and message-integrity (Re: Use Case draft - legacy interop)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2012 21:46:21 -0000

On 05/07/2012 11:23 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>> Sent: Monday, May 07, 2012 2:15 PM
>> To: Dan Wing
>> Cc: rtcweb@ietf.org
>> Subject: Consent freshness and message-integrity (Re: [rtcweb] Use Case
>> draft - legacy interop)
>>
>> Forking the thread, since this is a different detail.....
>>
>> On 05/05/2012 07:24 PM, Dan Wing wrote:
>>> The other nuance is that, because
>>> doing the SHA1 for MESSAGE-INTEGRITY isn't needed for consent
>> freshness,
>>> there is desire to allow those periodic ICE connectivity checks to
>>> omit the MESSAGE-INTEGRITY, which is a change to ICE.  See
>>> draft-muthu-behave-consent-freshness.
>> Omitting MESSAGE-INTEGRITY would allow off-path attackers to inject
>> fake
>> connectivity checks, and thus to simulate continued consent.
> To successfully do that, those off-path attackers would have to guess
> the random 96-bit STUN transaction-id.
You're right, successfully replying to consent freshness packets 
requires read access to the consent freshness packets being sent (I was 
thinking that consent freshness was being generated from the recipient, 
not the sender, which is opposite to what draft-muthu does .... or 
rather, it's not clear to me what direction a successful 
request/response exchange verifies the freshness of). So it's an on-path 
attacker. I'll go take that argument to behave; I don't think that 
tradeoff is in the right place.

v2.23.0 | Report a Bug | By Email