[secdir] SecDir review of draft-ietf-tram-turn-server-discovery-08

"Brian Weis (bew)" <bew@cisco.com> Fri, 12 August 2016 02:50 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA912D10F; Thu, 11 Aug 2016 19:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.767
X-Spam-Level:
X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 QQs33cnzXuaW; Thu, 11 Aug 2016 19:50:06 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD4112B015; Thu, 11 Aug 2016 19:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12516; q=dns/txt; s=iport; t=1470970206; x=1472179806; h=from:to:cc:subject:date:message-id:mime-version; bh=loCVFEcjYHpK+w8NE94O3XUzGeoAq7a1XveZgU072cA=; b=dEaMklBUl+vU3FVRivFzfmJM6BC1xfqgQeS+gAsnf+QVPCpgghGOUyaQ 61rZjT+UMTnuxk2PeuHP/8vBu6jjlj5trbe0f+2qVUO+bxLaMEpeIvVHM cJsFIAtwa3NO2bW/8Gx+kUec4HKZXI1CxZH3UBqyJVNvVmjWbal0zxg+L M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAgD2OK1X/5tdJa1egndOgVm0HYUHg?= =?us-ascii?q?X2GHR6BOjgUAQEBAQEBAV0nhGUjVhIBSgIEMCcEAQ2INrBQkDABAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEciCKGf4MXK4IvBZN4hUQBjxOPQ5AsAR42g3qGVisZfwEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.28,508,1464652800"; d="scan'208,217";a="309925395"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Aug 2016 02:49:45 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7C2niqE029851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Aug 2016 02:49:44 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 Aug 2016 22:49:43 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 11 Aug 2016 22:49:43 -0400
From: "Brian Weis (bew)" <bew@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: SecDir review of draft-ietf-tram-turn-server-discovery-08
Thread-Index: AQHR9EQtsMc8iAoZw0eiSM9NE0uIMQ==
Date: Fri, 12 Aug 2016 02:49:43 +0000
Message-ID: <CB394607-8BE5-42C2-BD5A-8431F2C9CB83@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.191.172]
Content-Type: multipart/alternative; boundary="_000_CB3946078BE542C2BD5A8431F2C9CB83ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Owx3dMqNLYVwfeSz300ceON3g5E>
Cc: "draft-ietf-tram-turn-server-discovery.all@tools.ietf.org" <draft-ietf-tram-turn-server-discovery.all@tools.ietf.org>
Subject: [secdir] SecDir review of draft-ietf-tram-turn-server-discovery-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Aug 2016 02:50:08 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

I consider this draft to be Ready with nits.

TURN servers are used to connect devices running Peer-to-Peer applications, such as real-time communication. Typically these TURN servers are not under a local network’s administrative control (e.g., the enterprise or ISP hosting the communicating devices. This draft provides a server discovery method to a TURN server that is under the administrative control of the local network. There are some security and operational advantages to the use of a local TURN server, since the local service can tend to keep the real-time communication (or other application) messages from leaving the local network. This is useful. The methods for auto-discovering local TURN servers discussed in the document include DNS Service Resolution, DNS Service Discovery,  and Anycast.

The main security consideration of using using server discovery methods would seem to be ensuring that an authorized local STUN server has been reached. The Security Considerations section mentions STUN authentication as OPTIONAL for “TURN servers provided by the local network or by the access network”, but "it is RECOMMENDED that the TURN client use one of the following techniques with (D)TLS”. When (D)TLS is used, several mechanisms are described whereby the client can determine that a STUN server is authorized. The requirements language is a bit obscure, but the result is recommending that (D)TLS authentication and authorization is used, which is fine.

The Security Considerations section also recommends what a client ought to do when authenticated (D)TLS isn’t possible. The paragraph just before Section 9.1 contains good advice, but it could be clearer. For example the paragraph confuses privacy goals with the security goal of mitigating on-path injection of spoofed packets. I suggest rewording this paragraph with text something like this:

   In some auto-discovery scenarios, it might not be possible for the
   TURN client to use (D)TLS authentication to validate the TURN server.
   However, fall-back to clear text in such cases could leave the TURN
   client open to on-path injection of spoofed TURN messages.
   Instead, a TURN client SHOULD fall-back to encryption-only
   (D)TLS when (D)TLS authentication is not available. Another reason
   to fall-back to encryption-only is for privacy, which is
   analogous to SMTP opportunistic encryption
   [RFC7435]  where one does not require privacy but one desires privacy
   when possible.

   It is suggested that a TURN client attempt (D)TLS with
   authentication and encryption, falling back to encryption-only if the
   TURN server cannot be authenticated via (D)TLS.  The TURN server
   could fall back to clear text if it  does not support unauthenticated (D)TLS,
   but fallback to clear text is NOT RECOMMENDED because it makes
   the client more susceptible to man-in-the-middle attacks and on-path
   packet injection.

The Security Considerations in each of the sub-sections is good as written.

Brian