Re: [rtcweb] Consent alternative

Martin Thomson <martin.thomson@gmail.com> Tue, 03 December 2013 16:55 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC01AE120 for <rtcweb@ietfa.amsl.com>; Tue, 3 Dec 2013 08:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLzUEmZy9hTU for <rtcweb@ietfa.amsl.com>; Tue, 3 Dec 2013 08:55:26 -0800 (PST)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CC4081A1F74 for <rtcweb@ietf.org>; Tue, 3 Dec 2013 08:55:25 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id z2so5333113wiv.13 for <rtcweb@ietf.org>; Tue, 03 Dec 2013 08:55:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h+8vO/MWFI0v+hh28Hw5OkBM2XJxh68t7jetbw5M8zc=; b=gPKLBzBTpgaB0CdqEDBTEKvhJMU8BRqyqT+XbGEXdVJSDnmxBi64uujZnV7GOs8awZ 2fOjZO+FQhAcDnnNrwM3x8jwutLoTXSR84VgrSqtFbBA1xq/J7w3eb++ZPkSusNkKu6R kvGvl68U/0/4+4kAZbMUdc9wXXQhJCbBBWTSwpOSxir0Vd7GoWitsAz/s9G1w/rYwZ1Z dYMm0o2nR/4dZ3WfbCogN9oBL3dBbWMYj7nWSPPFD938e3G0A6peefCC/V3YaoMfb71/ 4USRVlunRchY7fm4f3fCFhBhi3LFB1XF4GDBXyuTpiH7KcJHKjHI6zIVe7Yacv5UvBIf wgGw==
MIME-Version: 1.0
X-Received: by 10.194.232.133 with SMTP id to5mr7890792wjc.41.1386089722757; Tue, 03 Dec 2013 08:55:22 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Tue, 3 Dec 2013 08:55:22 -0800 (PST)
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE22437073A@xmb-rcd-x02.cisco.com>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com> <52989933.6000907@ericsson.com> <CABkgnnUX3OFUyc5PXeN0ydykBwL0HyRuaigfJKMBbuWnuhnVJg@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22436FBD9@xmb-rcd-x02.cisco.com> <CABkgnnUy3HxvsqYfwspEQ9_g1frUuFF4rwD-hTz45UzCr1fTBw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22437073A@xmb-rcd-x02.cisco.com>
Date: Tue, 3 Dec 2013 08:55:22 -0800
Message-ID: <CABkgnnVOuG9pNRA8RzBYOhTHUih0RASchVHxYsnYQk8fDs_VLA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: text/plain; charset=UTF-8
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consent alternative
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 03 Dec 2013 16:55:28 -0000

On 3 December 2013 04:48, Muthu Arul Mozhi Perumal (mperumal)
<mperumal@cisco.com> wrote:
> That's a typical third party call control (3PCC) use case where B (3PCC)
> mangles call signaling + SDP b/w A and C and sets up the media session
> between them. The security of ICE (as defined in RFC5245) is rooted in the
> ice-ufrag and ice-pwd exchanged in call signaling. If a 3PCC can mangle
> them, ICE can't prevent the connectivity check from succeeding.
>
>
>
> If it is deemed a problem, it might need an ICE extension to fail the
> connectivity check b/w A and C.

I think that you have missed the point here.  The point is that A and
B share a DTLS connection, and B uses ICE to convince A to send
packets for that connection to C.  All this requires is that B is able
to spoof the source address of packets to appear as coming from C.
It's got nothing to do with 3PCC scenarios.