[BEHAVE] [Errata Rejected] RFC5766 (4933)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 17 February 2020 09:48 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 3542A120800; Mon, 17 Feb 2020 01:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 kue-iztPPkzL; Mon, 17 Feb 2020 01:48:42 -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 8227F1207FF; Mon, 17 Feb 2020 01:48:42 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 3C885F40710; Mon, 17 Feb 2020 01:48:40 -0800 (PST)
To: shakeeb@eyeball.com, rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@jdrosen.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: magnus.westerlund@ericsson.com, iesg@ietf.org, behave@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200217094840.3C885F40710@rfc-editor.org>
Date: Mon, 17 Feb 2020 01:48:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/1Lhy55BfJ4Hpudzz8fjUkvBQ414>
Subject: [BEHAVE] [Errata Rejected] RFC5766 (4933)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 17 Feb 2020 09:48:45 -0000
The following errata report has been rejected 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: https://www.rfc-editor.org/errata/eid4933 -------------------------------------- Status: Rejected Type: Technical Reported by: shakeeb <shakeeb@eyeball.com> Date Reported: 2017-02-15 Rejected by: Magnus Westerlund (IESG) 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. --VERIFIER NOTES-- So TURN does not actually specify the usage of short-term credentials. It mandates support of long-term credentials as authentication mechanism. Also RFC 7635 (STUN for Third party Authorization) specifies how to handle expire of the access token. This is clearer in the replacement of RFC 5766 that will soon be published that specifies the following in Section 7.2: If the request is authenticated, the authentication MUST be done either using the long-term credential mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for Third-Party Authorization [RFC7635] unless the client and server agree to use another mechanism through some procedure outside the scope of this document. -------------------------------------- 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
- [BEHAVE] [Errata Rejected] RFC5766 (4933) RFC Errata System