Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
Harald Alvestrand <harald@alvestrand.no> Wed, 25 September 2013 12:14 UTC
Return-Path: <harald@alvestrand.no>
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 3B5BD21F9FBF for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 05:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.371
X-Spam-Level:
X-Spam-Status: No, score=-110.371 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, 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 0G2aAKGAMbdF for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 05:14:15 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3992B21F9FAB for <pntaw@ietf.org>; Wed, 25 Sep 2013 05:14:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9839B39E1BB for <pntaw@ietf.org>; Wed, 25 Sep 2013 14:14:12 +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 O2W6FcKBe-52 for <pntaw@ietf.org>; Wed, 25 Sep 2013 14:14:10 +0200 (CEST)
Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E4AB939E0BF for <pntaw@ietf.org>; Wed, 25 Sep 2013 14:14:10 +0200 (CEST)
Message-ID: <5242D393.4070500@alvestrand.no>
Date: Wed, 25 Sep 2013 14:14:11 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: pntaw@ietf.org
References: <52411CD5.1050909@gmail.com> <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com> <5241BB6D.2000104@gmail.com>
In-Reply-To: <5241BB6D.2000104@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Wed, 25 Sep 2013 12:14:20 -0000
On 09/24/2013 06:18 PM, Melinda Shore wrote: > 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. So Melinda, if I read you right, the attack you're envisioning is not against the communication, but something like this: client -> STUN server: What's my address? firewall (tells nobody): installs a NAT mapping & pinhole for client that allows real traffic from anywhere Evil STUN server -> client: your address is <something> Evil STUN server -> Evil attacker: You can now reach <client> at <real address> If this is a port-NAT, the port opened by <client> is now accessible from the Internet. If it's an address NAT, the whole host is - but that's unlikely in the firewall case, isn't it? I'm not sure authentication helps here - once you've sent off a request to the evil server, you've opened the hole. It would even be good for the evil server to give a correct answer, since that increases the chances that the hole would remain open - you'll be using it. But - all those packets will end up at the WebRTC client. And that had *better* be hardened against outsiders anyway, because that hole *is* going to be open. How valuable is this attack vector? > > 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 > > _______________________________________________ > pntaw mailing list > pntaw@ietf.org > https://www.ietf.org/mailman/listinfo/pntaw
- [pntaw] More on draft-hutton-rtcweb-nat-firewall-… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Simon Perreault
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Dan Wing
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Harald Alvestrand
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Dan Wing
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Hutton, Andrew