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;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****
>>
>> ** **
>>
>
>