[BEHAVE] [Technical Errata Reported] RFC5766 (4933)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 15 February 2017 10:41 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235A1294E1 for <behave@ietfa.amsl.com>; Wed, 15 Feb 2017 02:41:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpmfjoBg8dd4 for <behave@ietfa.amsl.com>; Wed, 15 Feb 2017 02:41:21 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11801294D8 for <behave@ietf.org>; Wed, 15 Feb 2017 02:41:21 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id BE127B81039; Wed, 15 Feb 2017 02:41:21 -0800 (PST)
To: rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@jdrosen.net, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, dwing@cisco.com, dthaler@microsoft.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20170215104121.BE127B81039@rfc-editor.org>
Date: Wed, 15 Feb 2017 02:41:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/Ou9quAvkSwV3y8gmNe5xRPV8jnM>
Cc: shakeeb@eyeball.com, text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, behave@ietf.org, charset=UTF-8@rfc-editor.org
Subject: [BEHAVE] [Technical Errata Reported] RFC5766 (4933)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 10:41:23 -0000

The following errata report has been submitted for RFC5766,
"Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5766&eid=4933

--------------------------------------
Type: Technical
Reported by: shakeeb <shakeeb@eyeball.com>

Section: 17.3.3

Original Text
-------------
An attacker might attempt to disrupt service to other users of the
TURN server by sending Refresh requests or CreatePermission requests
that (through source address spoofing) appear to be coming from
another user of the TURN server.  TURN prevents this by requiring
that the credentials used in CreatePermission, Refresh, and
ChannelBind messages match those used to create the initial
allocation.  Thus, the fake requests from the attacker will be
rejected.

Corrected Text
--------------


Notes
-----
When using short-term, credentials expire after a specific amount of time (such as 5
minutes)  and clients get new credentials. The restriction imposed at section 17.3.3 
prevents from refreshing allocation or permission using the new credentials.

This RFC approves RFC 5389. So one can use short-term credentials.  But short-term credentials are useless if it can not be used to refresh allocation or permission.


The goal of 17.3.3 can be achieved by sending 438 with the new nonce.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5766 (draft-ietf-behave-turn-16)
--------------------------------------
Title               : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
Publication Date    : April 2010
Author(s)           : R. Mahy, P. Matthews, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : Behavior Engineering for Hindrance Avoidance
Area                : Transport
Stream              : IETF
Verifying Party     : IESG