Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
Oleg Moskalenko <mom040267@gmail.com> Tue, 24 September 2013 15:07 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 6E77511E814E for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 08:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.414
X-Spam-Level:
X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.029, 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 0y286LIfmc6G for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 08:06:59 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A8C8511E8156 for <pntaw@ietf.org>; Tue, 24 Sep 2013 08:06:59 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id kl14so3782829pab.25 for <pntaw@ietf.org>; Tue, 24 Sep 2013 08:06:43 -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=Xu6lIFa5Yn5QwDx8zbTvpWYMypYZaodUWHG5oJ7h/W0=; b=s0+rcVPTlJjZghMRHgNIxbrVdrSWAlndQ6iiodUfwkPinhtRoAnsS7YDAbeOH09tTZ pgV5TzfncBCGHiMQqSBl+qy3WGyjhR9aPHvQqo+2yI15oov6g6xo2MMMRgPt+Qzxx4wF i8U5guzz3V2HciEBNQ4WiZOj45HGGa67afJQT3j0jSEvxJOrtpo+hLMEvH0zAcwQjBKk h97uMnP5CDh+qAklM1crt/ADbmjTcquvHwt2KFLViyIDPLWsW6+tqiptBT6VBc9gIHL1 EmcxS0cWcG4gNnNzhmcsIh2YN//LekM+iNcsHoL9KSmxatQrHVQY/CU72p2fxNEQwzDm xXWA==
MIME-Version: 1.0
X-Received: by 10.68.98.36 with SMTP id ef4mr4907800pbb.27.1380035203593; Tue, 24 Sep 2013 08:06:43 -0700 (PDT)
Received: by 10.68.91.163 with HTTP; Tue, 24 Sep 2013 08:06:43 -0700 (PDT)
In-Reply-To: <CALDtMrKOdWSRxM4c_XW7rv6_hTcsa_Zp2A+83zoK3+fHYR0rrA@mail.gmail.com>
References: <52411CD5.1050909@gmail.com> <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com> <CALDtMrKOdWSRxM4c_XW7rv6_hTcsa_Zp2A+83zoK3+fHYR0rrA@mail.gmail.com>
Date: Tue, 24 Sep 2013 08:06:43 -0700
Message-ID: <CALDtMr+aPQjr2BDrO2AHrp5_ppgN3R=Tjw7C4nPAJR6EAS_HYw@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Content-Type: multipart/alternative; boundary="047d7b6d85f216820604e7227c83"
Cc: Melinda Shore <melinda.shore@gmail.com>, "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 15:07:01 -0000
Melinda also probably implied a similar problem with TURN and relayed addresses, but that problem is addressed by the TURN security mechanism, as in section 17.1.5 of RFC 5766. On Tue, Sep 24, 2013 at 7:37 AM, Oleg Moskalenko <mom040267@gmail.com>wrote: > Hi Tiru, > > Melinda was talking about a different area of concern. She was considering > an attack when a malicious party sends a fake STUN Binding response to the > client. Then, the client will have wrong value of its own reflexive IP > address and the client will use that wrong address in, say, SDP. Then the > peer will be sending the media stream to the attacker's IP address. > > As STUN Binding request/response dialog is usually implemented without > authentication in the STUN/TURN servers, that may be really a concern. > > Oleg > > > > On Tue, Sep 24, 2013 at 2:19 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> 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.**** >> >> ** ** >> >> -Tiru.**** >> >> *From:* pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] *On >> Behalf Of *Oleg Moskalenko >> *Sent:* Tuesday, September 24, 2013 12:50 PM >> *To:* Melinda Shore >> *Cc:* pntaw@ietf.org >> *Subject:* Re: [pntaw] More on >> draft-hutton-rtcweb-nat-firewall-considerations**** >> >> ** ** >> >> 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