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

Oleg Moskalenko <mom040267@gmail.com> Tue, 24 September 2013 06:46 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 494AC21F9468 for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 23:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.405
X-Spam-Level:
X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.038, 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 vE4XCn4eT999 for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 23:46:19 -0700 (PDT)
Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0EB21F9385 for <pntaw@ietf.org>; Mon, 23 Sep 2013 23:46:16 -0700 (PDT)
Received: by mail-pb0-f46.google.com with SMTP id rq2so4172441pbb.19 for <pntaw@ietf.org>; Mon, 23 Sep 2013 23:46:15 -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=tA8HwP7lUNVae3fWgNAUJQlyHNG4h3fgOVPswdwiGXQ=; b=IWv297wZlE8SsH/vZ3DKxBi8oA0jw1LH9qVdCwH6OWm5Ovslljb3OLw5s6ruVSqlJm QfRv9XcXm/y5ltLD0cPSlwR10fdJO0baz0xdBQ18GipPDDbs1ETANTUHBQAk7YyevLG3 7+H66C6bchvdM9eGIjOYdGbswyL0LmzNNeeT62gAzuVEeD+fyyhzx/ON5B4nM2VCVoJw 6jrrV2axuBb7VVkYPT5nEffpQccV9Rc0ZLO+RFF/jifvzRsIAqasbnGhLF7lAOxOKDSw xMROyXJ1y6QO8ImVUeiCrAR1SfWUmAhkDM7eHwE+7N9b63GL76cD+Qlxlr95fPCq2CHs 2atw==
MIME-Version: 1.0
X-Received: by 10.68.98.36 with SMTP id ef4mr3322768pbb.27.1380005174976; Mon, 23 Sep 2013 23:46:14 -0700 (PDT)
Received: by 10.68.91.163 with HTTP; Mon, 23 Sep 2013 23:46:14 -0700 (PDT)
In-Reply-To: <52411CD5.1050909@gmail.com>
References: <52411CD5.1050909@gmail.com>
Date: Mon, 23 Sep 2013 23:46:14 -0700
Message-ID: <CALDtMrLNgeMvxqRov92++7EuaxOgtnfHQZWoaGkn+AydLOgmJA@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Melinda Shore <melinda.shore@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b6d85f23e28d504e71b7e9a
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 06:46:23 -0000

On Mon, Sep 23, 2013 at 10:02 PM, Melinda Shore <melinda.shore@gmail.com>wrote;wrote:

> I think you really need to be clearer about the distinction
> between NAT and firewall, and that firewalls are policy
> enforcement devices.


this distinction is a sort of academic exercise. I am not sure that
concentrating on that theoretical distinction has much of practical value
in the real world.


>
> I can give you a long, long list of reasons I don't like
> STUN (and, to a lesser extent, TURN),


For a person who does not "like" STUN and TURN you are dedicating too much
efforts to discussing them.


> 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.


TURN responses are always authenticated, if any security mechanism is
chosen. The client must check the integrity-field to authenticate the
response. Only the entity who knows the user password can construct a valid
response.

The only unauthenticated response (usually) is STUN "binding" response.
This is just an implementation convention that it is usually
unauthenticated. Nothing in RFC requires it to be unauthenticated. That's
only a common practice to leave it unauthenticated. For secure
environments, we can always enforce authentication of the BINDING response.



> 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.
>

In very secure environments, the short-term authentication TURN mechanism
can be used. Each TURN Send and Data indications are authenticated in that
case. Then no application level authentication is necessary.

TURN is really a neat and clever tool, when you do understand how it works.