Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations

Melinda Shore <melinda.shore@gmail.com> Tue, 24 September 2013 16:18 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61C321F9C05 for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 09:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
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 QPUYJk8TA8X9 for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 09:18:58 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 38EF421F9C0D for <pntaw@ietf.org>; Tue, 24 Sep 2013 09:18:58 -0700 (PDT)
Received: by mail-pa0-f49.google.com with SMTP id ld10so5141768pab.8 for <pntaw@ietf.org>; Tue, 24 Sep 2013 09:18:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vBnzGVdhLL0mKAIQKDOt48oNtCTEC6QHDYwcuZeR7u0=; b=LV9mrNQPh2pZ728Qh00nWyhtzrQrtcp3BJQPhI903o1JpXF/WIMPZ13YOupNi6jDoa vELvMUq9zK6dfgiowZjHhJfoKmIniaSX4EopMPYEKRFXvXfrO/mOJ+Oil7nkIa7EadSi jgGKd2sKGg9xRlFCqPf4ikTBPTJQZ8odmBYu8fhG9y0mQ3YEq5n0PIu5Bq0bqhFNMdQA 8Ixr5bF+ZzBOH4LUmTvwCieHWUZDFP+Td8w09R29e5TpkO2O8T6vdSO4cvXel2QHyp23 g7D4ucoJtVihH7e6VJyEJgy2s6WGrjJjpvg4FGC+emPwoB4ZI5WKeC76iTmLMYuD0dka eWxA==
X-Received: by 10.68.137.1 with SMTP id qe1mr28428232pbb.25.1380039537884; Tue, 24 Sep 2013 09:18:57 -0700 (PDT)
Received: from spandex.local (63-140-98-62.dynamic.dsl.acsalaska.net. [63.140.98.62]) by mx.google.com with ESMTPSA id sn4sm37315284pbc.37.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 09:18:56 -0700 (PDT)
Message-ID: <5241BB6D.2000104@gmail.com>
Date: Tue, 24 Sep 2013 08:18:53 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
References: <52411CD5.1050909@gmail.com> <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2013 16:18:58 -0000

On 9/24/13 1:19 AM, Tirumaleswar Reddy (tireddy) wrote:
> We had discussed in BEHAVE WG to change TURN REST API draft to use
> OAuth. With OAuth, the WebRTC client will get self-contained token with
> lifetime, session key etc in the signaling protocol which will be used
> by the TURN client to compute message integrity for the TURN request.
> TURN server will use the token to get the session key, validate the TURN
> request and also compute the message integrity for the TURN response.
> This solves the problem of not exposing long-term credentials to the
> java script.

The primary win, I think, is that  by allowing someone you trust
to say "Yes, this user is authorized to perform this action" it
provides some mitigation against the possibility of abuse by
an attacker wishing to punch holes in your firewall.  OAuth
is not, strictly speaking, an authentication mechanism, although
it may look that way to the relying party.  How the user authenticates
to the IdP is, strictly speaking, out of scope, here.

Authentication on its own is probably not sufficient.  Just because
I can prove who I am doesn't mean that I am permitted to punch
holes through the firewall, at least not in the general case,
and while I think you're likely to run into resistance if you
try to roll your own authorization token I do think that you'll
need something to be able to authorize hole-punching.

I'll reiterate that I think you need to deal with the firewall
vs. NAT distinction if you want to get this document through
IETF review, should it ever progress that far.  STUN and TURN have
not been used for creating firewall pinholes before, at least not
in the IETF.

Melinda