Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Tue, 16 July 2013 10:49 UTC

Return-Path: <mperumal@cisco.com>
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 C076E11E80AE; Tue, 16 Jul 2013 03:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.399
X-Spam-Level:
X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Qfj1aG5b7bxd; Tue, 16 Jul 2013 03:49:10 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3E63321E8091; Tue, 16 Jul 2013 03:49:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6594; q=dns/txt; s=iport; t=1373971750; x=1375181350; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Po4m7Ra9CAvA43jLU366UxgT7gkxW2+ystwk/lVI/Pw=; b=b6mw8HJ6RG/DecOFPmBRKVNGzhf5V7loTsQTSXnRU694P1sdWJAgqlm7 pzEPSPpwSVySXNvGshmZlJ1I+qQLXrDIDgrKNq7xo8F2xIAgwfuysxoTe kpbXplFshrSM2QItDCCaSdNDavsV/ohtp8neskPeFsXwfu4RJl/3BIo7Y M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFADck5VGtJXG//2dsb2JhbABagwY0T8FegREWdIIjAQEBBAEBAWsXBAIBCBEEAQELDg8HJwsUCAEIAgQBEggTh3UMthoEjzM4BhKCc20DiG+UYYtZgxKBaiQa
X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="235447897"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2013 10:49:08 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GAn8nW007407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 10:49:08 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 05:49:07 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, "behave@ietf.org" <behave@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Thread-Index: AQHOggfD5W/HlPrVS02D/hotnG5s6plnD7Qg
Date: Tue, 16 Jul 2013 10:49:07 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE224199A15@xmb-rcd-x02.cisco.com>
References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <E721D8C6A2E1544DB2DEBC313AF54DE224198182@xmb-rcd-x02.cisco.com> <51E513BF.2040405@viagenie.ca>
In-Reply-To: <51E513BF.2040405@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.163.208.173]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
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, 16 Jul 2013 10:49:15 -0000

[Added rtcweb since I am not sure if everyone involved there are following this discussion in behave]

Thanks for the review. See inline.. 

|-----Original Message-----
|From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a écrit :
|> The text and the algorithm in the draft are significantly simplified in this updated version.
|>
|> Comments welcome..
|
|MUCH better introduction. Now I feel like I understand the need exactly.
|
|The "Design Considerations" section is still very confusing to me.
|
|>    Though ICE specifies STUN Binding indications to be used for
|>    keepalives, it requires that an agent be prepared to receive
|>    connectivity check as well.  If a connectivity check is received, a
|>    response is generated, but there is no impact on ICE processing, as
|>    described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE restart..

|
|>    While a WebRTC browser could verify whether the peer continues to
|>    send SRTCP reports before sending traffic to the peer, the usage of
|>    SRTCP together with Security Descriptions [RFC4568] requires exposing
|>    the media keys to the JavaScript and renders SRTCP unsuitable for
|>    consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"? Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet.

|
|>    For consent, calculating the SHA1 HMAC is necessary for MESSAGE-
|>    INTEGRITY which is computationally expensive.
|
|You need to qualify "expensive". It's certainly not expensive in all cases.
|
|>    Security analysis
|>    concluded that the STUN 96 bits transaction ID is sufficient for
|>    consent, without needing MESSAGE-INTEGRITY.
|
|What analysis? You would need to explain it in detail. But if that's not
|part of your suggested solution, just remove the sentence.

Agree it could be elaborated. The intention was to say the foll:

   STUN requires the 96 bits transaction ID to be uniformly and randomly
   chosen from the interval 0 .. 2**96-1, and be cryptographically
   random. This should suffice to prevent off path attacks on consent 
   freshness, so MESSAGE-INTEGRITY is not necessary from a security
   perspective.

However, MESSAGE-INTEGRITY is still used to maintain backward compatibility 
with legacy ICE/ICE-lite implementations.

|
|Now on to section "4. Solution Overview"...
|
|>    Every Tc seconds, the WebRTC browser sends a STUN Binding Request to
|>    the peer.  This request MUST use a new, cryptographically random
|>    Transaction ID [RFC4086], and is formatted as for an ICE connectivity
|>    check [RFC5245].  A valid STUN Binding Response is also formatted as
|>    for an ICE connectivity check [RFC5245].  The STUN Binding Request
|>    and STUN Binding Response are validated as for an ICE connectivity
|>    check [RFC5245].
|
|Couldn't this whole paragraph be simplified to "Every Tc seconds, the
|WebRTC browser sends an ICE connectivity check."? Is there anything new
|here besides the "every Tc" thing?

The difference from the ICE connectivity check is that there is no exponential back off for retransmissions.
 
|
|>    Liveness timer: If no packets have been received on the local port in
|>    Tr seconds, the WebRTC browser MUST inform the JavaScript that
|>    connectivity has been lost.  The JavaScript application will use this
|>    notification however it desires (e.g., cease transmitting to the
|>    remote peer, provide a notification to the user, etc.).
|
|This seems to me like it will not fulfill the goal set in the abstract:
|"to ensure that a malicious JavaScript cannot use the browser as a
|platform for launching attacks". If the JavaScript is free to ignore the
|notification from the browser, then it has no security benefits. If you
|want to reach that goal, the browser needs to forcefully stop transmitting.

That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on that candidate pair, including liveness checks, if there is a consent failure.

|
|>    When not actively sending traffic on a nominated candidate pair,
|>    performing consent freshness does not serve any purpose from a
|>    security perspective.
|
|I don't understand what this means. Why is the "security perspective"
|important here? Aren't we concerned about keepalives?

You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness would be required for sending them as well?

|
|>    In ICE [RFC5245] the STUN request/response are protected with
|>    MESSAGE-INTEGRITY, using an ephemeral username and password exchanged
|>    in the SDP ice-ufrag and ice-pwd attributes.  This prevents ICE from
|>    accidentally connecting to an in-intended peer, in that ICE will only
|>    connect to a peer that also knows the same username and password
|>    (exchanged in call signaling).  Once that connection to the remote
|>    peer has been established with ICE, the consent to continue sending
|>    traffic does not benefit from re-asserting that same username and
|>    password, so long as the senders and receiver's IP addresses remain
|>    the same (as they usually do).
|
|I had not understood from the text that there was no auth stuff in the
|request. The text said "This request [...] is formatted as for an ICE
|connectivity check [RFC5245]." I thought that included auth stuff.
|
|The explanation why no auth stuff in the request is acceptable should be
|moved to section 3.

Agree, it could be moved under design considerations.

Muthu 

|
|Simon
|_______________________________________________
|Behave mailing list
|Behave@ietf.org
|https://www.ietf.org/mailman/listinfo/behave