[rtcweb] consent freshness and ICE-lite

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Tue, 17 July 2012 01:12 UTC

Return-Path: <richard.ejzak@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1660D11E8088 for <rtcweb@ietfa.amsl.com>; Mon, 16 Jul 2012 18:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.033
X-Spam-Status: No, score=-10.033 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id f-96Z9tW2McW for <rtcweb@ietfa.amsl.com>; Mon, 16 Jul 2012 18:12:11 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 1387D11E8087 for <rtcweb@ietf.org>; Mon, 16 Jul 2012 18:12:10 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com []) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6H1CsCG017260 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rtcweb@ietf.org>; Tue, 17 Jul 2012 03:12:54 +0200
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com ( by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ( with Microsoft SMTP Server (TLS) id; Tue, 17 Jul 2012 03:12:54 +0200
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([]) with mapi id 14.02.0247.003; Mon, 16 Jul 2012 21:12:52 -0400
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] consent freshness and ICE-lite
Thread-Index: Ac1juUkxXazx0L/8TeuPdppctANNtw==
Date: Tue, 17 Jul 2012 01:12:52 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F17709B1B@US70UWXCHMBA04.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F17709B1BUS70UWXCHMBA04z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
Subject: [rtcweb] consent freshness and ICE-lite
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: Tue, 17 Jul 2012 01:12:12 -0000

Sections 4.2, 4.4 and 5.3 of draft-ietf-rtcweb-security-arch-03.txt have text that seems to be contradictory.  In particular, 5.3 requires support of ICE-lite at server gateways but each endpoint is described as sending ICE binding requests for ICE consent verification in 4.2 (which is it?).  4.4 also requires RTCWeb implementations to perform periodic binding requests to verify consent freshness.  Is a server gateway an RTCWeb implementation subject to this requirement?  I thought that one of the reasons the WG decided to use binding requests instead of binding indications to allow bilateral consent initiated by a single endpoint (in particular, so that an RTCWeb browser could interoperate with either a server gateway implementing ICE-lite or a non-RTCWeb endpoint not implementing the RTCWeb consent freshness procedures in such a way that only the RTCWeb browser needed to send periodic binding requests to maintain bilateral consent freshness).

Does a binding request provide unilateral or bilateral consent verification/freshness?

Is a server gateway implementing ICE-lite required to send ICE binding requests anyway for consent verification and/or consent freshness, or is it sufficient for such an implementation to indicate its own consent by just responding to received binding requests?

Do we care about compatibility with ICE compliant endpoints that do not use binding requests for consent freshness?

Does a browser treat a response to a binding request the same as a received binding request for consent freshness?

It would be helpful to have clear answers to these questions in the security architecture document.


Richard Ejzak