Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
Oleg Moskalenko <mom040267@gmail.com> Tue, 24 September 2013 07:20 UTC
Return-Path: <mom040267@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 19C7C21F9CC6 for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 00:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Level:
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 xLMniwpWxjHu for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 00:20:19 -0700 (PDT)
Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 34DBE21F9CC2 for <pntaw@ietf.org>; Tue, 24 Sep 2013 00:20:18 -0700 (PDT)
Received: by mail-pb0-f49.google.com with SMTP id xb4so4206586pbc.22 for <pntaw@ietf.org>; Tue, 24 Sep 2013 00:20:18 -0700 (PDT)
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=NVWfVKHipyPZiqC4i6nJitNDWWcsxsIpLpwQKMEApaA=; b=YwWNWXpkIJi/gzLq1BLOAyiqgOFI5gm91P4m//9DNcO71DnPmvOOUtziR6W3mceEh4 okUlotYXcr//hk3qWf/UyK518yIUV8OEZqdgWs+SC71KjyUvTcCqfwZ3uR12iElbR1cW kEooJQp8CwaMO3oKCb7/w8Tj8xju2T68dU5Frzxa1BOQc12TU/XiqXC3lmMeDYfi86Oy 7f4clAlxBU6F5lvVsAvZysOnJQrafrDTARdkcswI7dmAqchP9dAVIDAgJzl2iEyB1LTT THvxusCsl1GxedWHtYIAtKhgv/kdxcqk3mXhT9zCQezxNR8B5cT1xSdJq+Kc0pE9o9Xo XCOQ==
MIME-Version: 1.0
X-Received: by 10.68.134.6 with SMTP id pg6mr26148422pbb.67.1380007217914; Tue, 24 Sep 2013 00:20:17 -0700 (PDT)
Received: by 10.68.91.163 with HTTP; Tue, 24 Sep 2013 00:20:17 -0700 (PDT)
In-Reply-To: <52411CD5.1050909@gmail.com>
References: <52411CD5.1050909@gmail.com>
Date: Tue, 24 Sep 2013 00:20:17 -0700
Message-ID: <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Melinda Shore <melinda.shore@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b10cebf02eb3304e71bf8d0"
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 07:20:20 -0000
Melinda raised some valid TURN security concerns. I'd suggest to add two optional recommendations for the secure TURN environments: 1) Enforce authentication of STUN Binding request/response; 2) Short-term authentication mechanism. The problems with those recommendations are: 1) The existing STUN, TURN, WebRTC and ICE implementations do not support authenticated STUN Binding request/responses; this is an implementation problem, this is not a standard problem. I personally can say that adding an option of authenticated STUN request/response to our TURN server (rfc5766-turn-server) is an easy 1-hour work, but this is rather a convention problem. My experience is that once this option is enabled, the WebRTC stops working - it is not expecting a challenge response from the STUN server. It can be considered as a bug of the existing WebRTC libraries. 2) As of now, WebRTC does not support short-term authentication mechanism. 3) The new TURN REST API standard (under development) is revolving around the long-term authentication mechanism. On Mon, Sep 23, 2013 at 10:02 PM, Melinda Shore <melinda.shore@gmail.com>wrote: > I think you really need to be clearer about the distinction > between NAT and firewall, and that firewalls are policy > enforcement devices. NATs arguably are (address policy) > but to the extent they're deployed as access control > mechanisms that function is incidental to their design. > This matters a lot when you're talking about ICE, since > it was designed as a *NAT* traversal mechanism, not a > firewall traversal mechanism. There's been a long history > of highly contentious middlebox work in the IETF and > it's probably better to address those questions sooner > rather than later, as I think they're bound to come up. > > So, you're extending ICE to firewall traversal, because > ... ? > > In particular I'd put some text in section 1 addressing > the difference between NATs and firewalls, the policy > enforcement role of firewalls, that it is explicitly > not the intention of this draft to propose a mechanism > for violating local firewall policy, and that you recognize > a need to give the network administrator control over > what does and does not enter their network. That said, > if they do wish to allow WebRTC traffic, this is how to > do it. I think that will help fend off irritating questions > from people like, say, me. > > I think there's probably a lot more that can be said about > addressing and policy, particularly around authenticity, but > I'm going to save that for after having re-read the WebRTC > documents. But I'd like to skip ahead to the security > considerations section, because that's really critically > important and can't be left empty (to be honest I'm considering > proposing to my own working group and others that we not > adopt any working group draft that has an empty security > considerations section - it's a big problem). > > I think there are two broad classes of security issues here: > 1) the security of the mechanism itself, and > 2) security in the context of the environment > > In this case the two are not cleanly separable, to the > extent that presumably the reason for subverting the > security of a WebRTC traversal mechanism would be to > compromise the firewall (with one prominent exception, which > I'll get to below). > > As I mentioned in previous email, you cannot allow the > WebRTC firewall traversal technology to be subverted > to allow "unauthorized" pinholing. This is kind of a > messy problem, since it can involve port numbers (which > doesn't apply in the creation of real-time media > streams), stateful traffic inspection (which doesn't > work in the presence of encrypted signaling traffic), > and so on. It *may* be the case that there's an authoritative, > trusted entity somewhere in the application architecture > that can make authoritative statements about what's > allowed, and you could leverage a third-party mechanism > like OAuth if you can live with the added latency. > > I can give you a long, long list of reasons I don't like > STUN (and, to a lesser extent, TURN), but prominent among > them is that without some sort of application-layer > authentication it is trivially easy to use it to hijack media > streams. All you have to do is send a bogus STUN or > TURN response with an address of your choosing, since the > answer is unauthenticated. Using TCP as the TURN > transport makes an attack more challenging but it doesn't > eliminate it entirely. In VoIP scenarios, what they typically > do is accept the response but then authenticate the > application traffic, so if they get a bogus response > the media streams can't be established, anyway. > So, either think about how to protect against an insertion > attack, or make it clear that you've got protection > available at the application layer. > > 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