Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Mon, 08 July 2019 14:18 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0A1201EC; Mon, 8 Jul 2019 07:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 483ZFm5wqlbF; Mon, 8 Jul 2019 07:18:46 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAE41201CD; Mon, 8 Jul 2019 07:18:45 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562594892; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=GETm54WgCBWcPpWyWH+NxVojeB5cjpXhTG2ith 8H9+g=; b=OQwX5+D+kEIXRMn7K2Nq4GmtzrypnzY0yuJV3OEL iuXPc3NAEbjLriA7ClHAGlhG+R9FdUqlKFEJOOyihopGfYtQ4c YubIcqFrU/kxOgf0g+Mzeg8udOJ8zCVLsQZODHdATf1SXayq1Q y5Un2+cp2IWnh728JaVEyB4ALd5tdGc=
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 607d_9297_f2b6f823_38b6_40ce_a733_aeaf1269efd4; Mon, 08 Jul 2019 08:08:11 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:28 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 8 Jul 2019 08:18:28 -0600
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:26 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1403.namprd16.prod.outlook.com (10.173.215.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 14:18:26 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Mon, 8 Jul 2019 14:18:26 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Christopher Wood <caw@heapingbits.net>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBw
Date: Mon, 8 Jul 2019 14:18:26 +0000
Message-ID: <DM5PR16MB17057A838828AE1DFD33702AEAF60@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156253133809.549.13521510978566357744@ietfa.amsl.com>
In-Reply-To: <156253133809.549.13521510978566357744@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.8
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 933ce875-82a7-4a58-e040-08d703af2494
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1403;
x-ms-traffictypediagnostic: DM5PR16MB1403:
x-ms-exchange-purlcount: 11
x-microsoft-antispam-prvs: <DM5PR16MB140332249DA17796625AB935EAF60@DM5PR16MB1403.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00922518D8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(32952001)(51914003)(13464003)(199004)(189003)(5660300002)(76116006)(4326008)(73956011)(52536014)(66446008)(81166006)(14454004)(72206003)(186003)(66946007)(478600001)(476003)(81156014)(26005)(64756008)(6246003)(86362001)(966005)(8676002)(66476007)(66556008)(76176011)(53546011)(71200400001)(2906002)(8936002)(25786009)(7696005)(55016002)(486006)(71190400001)(66066001)(9686003)(6506007)(6306002)(3846002)(99286004)(68736007)(6116002)(229853002)(33656002)(2501003)(316002)(54906003)(305945005)(446003)(102836004)(80792005)(256004)(5024004)(74316002)(110136005)(14444005)(7736002)(6436002)(53936002)(11346002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1403; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GVZ/nyGTSnm/7dXWzIcqvhwsBj70cblOI7OGBk81+wmbWi6LfXECiY6gJEIMXLiqVp/irlsPFdZd1eMc9qd+1yjWBl+SG3P1JbkJc0t39Tue295/DTW+NS7cSVDrRWh3HmT+YqxnGULvA47vROlZLR3y+JtlWPkxCFXmBJjDuEmSv1D8UWs14oVPZEjdtCRHhiVV3tMJwl3cBoLyj89xKHd8k9Ms5nDDd37Mw16OL3KPIGkdOSh3SHj6RdOoc00TCbMu23O9bwqt900g92wAEs3HAqjEQV3ixTfPR+l7cdK9pZgkOYhblmqTFlif0Vgw0XmN+l4EvttQ13/tw6QyiYGKvfNTPwTkHoOOFh6XVARgWZa8MuvB4ngypW6D6uH5C4kVv+SzVOragZjlcDUZVRdxKKzQtdfd4XtUqwLwEME=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 933ce875-82a7-4a58-e040-08d703af2494
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 14:18:26.1669 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1403
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6585> : inlines <7115> : streams <1826746> : uri <2865133>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/yIAlowYAdL7yY3r_gaDQNTUXrwA>
Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2019 14:18:51 -0000

Hi Christopher,

Thanks for the detailed review. Please see inline

> -----Original Message-----
> From: tram <tram-bounces@ietf.org> On Behalf Of Christopher Wood via
> Datatracker
> Sent: Monday, July 8, 2019 1:59 AM
> To: secdir@ietf.org
> Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org
> Subject: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Reviewer: Christopher Wood
> Review result: Has Nits
> 
> 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.
> 
> The summary of the review is: Ready with nits
> 
> Summary:
> 
> In general, the document is well written and clearly founded in operational
> experience. The security considerations are thorough, providing examples
> where necessary to highlight important problem areas. It draws a clear line
> between issues best addressed by applications outside of TURN, and
> provides sufficient detail for those issues in scope. My comments and
> questions are, hopefully, mostly nits.
> 
> General comments:
> 
> - TURN server authentication in the case of (D)TLS is underspecified. Are
> servers assumed to have WebPKI certificates, OOB-trusted raw public keys,
> or something else? Is there a preferred form of authentication? 
> Relatedly, in
> Section 3.2, how do clients authenticate the server? 

Server certificate validation is discussed in https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3.  I have modified the text as follows:

If (D)TLS transport is used between the TURN client and the TURN server, the cipher suites,
server certificate validation and authentication of TURN server are
discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis]

>- Section 3.7: Could
> TURN servers not chunk data from stream-oriented transports (TCP or TLS)
> to a preferred MTU size before relaying to peers? 
> Specifically, there are likely
> some cases wherein the server could deal with the client data messages
> larger than the recommended 500B limit. On that point, should servers even
> accept data larger than this recommended size ? - 

Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 for TCP-to-UDP relay. If the PMTU is not known, and on legacy or otherwise unusual networks, 
500 byte limit for application data is recommended.

> Section 3.9: There may be
> cases where the TLS connection post TCP connection establishment fails. It
> would therefore seems prudent to not declare victory for one connection
> over the other until TLS connects, too. -

Agreed, Eric (as part of ISEG review) suggested to simplify the text. I have updated the text as follows:

   o  For TCP or TLS-over-TCP, the results of the Happy Eyeballs
      procedure [RFC8305] are used by the TURN client for sending its
      TURN messages to the server.

> Section 3 could benefit from a
> subsection on replays and the nonce role. In particular, as later discussed in
> the security considerations, some of these attacks are not new to TURN and
> should therefore be dealt with by the application protocol (SRTP). This
> section might also describe nonce rotation policies with more specificity, as
> this is underspecified in the document. 

It is discussed in Section 5 in the specification, the server should expire the nonce at least once every hour during the lifetime of the allocation.

>- Section 3 could also benefit from
> discussion about cleartext versus encryption transports between clients and
> servers.

It is discussed in https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-21.1.6. 

> Encrypting the nonce, username, realm, etc., among other things, has
> obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes
> recommended?  It seems like clients should be discouraged from sending
> these if anything, especially if not used to make allocation decisions on the
> server. 

Username may not be the user identity, Please see https://tools.ietf.org/html/rfc7635), It could be an ephemeral and unique key identifier. Further, username can be anonymized (please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4).   
SOFTWARE and FINGERPRINT attributes are defined in the STUN specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21. 

- Section 5: When servers receive data that exceeds an allocation’s
> bandwidth quota, servers silently discard this data. This means there’s no
> allocation-based flow control mechanism between client and server beyond
> what’s provided by the transport protocol, right? 

Yes, UDP does not include a congestion control mechanism.  

> This seems fine, though
> perhaps some discussion of why this design decision was made would be
> helpful. For example, I could imagine explicit signals from servers to clients
> that indicate server state would reveal information about other allocations
> on the server, which might be problematic. -

The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient Capacity)  do not reveal information of which other users are using the TURN server. 

> Section 7.2 suggests that
> servers can redirect client allocation requests to other servers. Can this
> create a loop, wherein two TURN servers redirect to one another? 

The client detect and stop the loop, it is similar to HTTP redirection.

> Moreover,
> is it acceptable for one TURN server to redirect to an unrelated TURN server?
> (It should be made clear here that these responses are authenticated, as
> otherwise it would be possible for an on-path adversary to redirect allocation
> requests to a server it owns.) 

It is already discussed in https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10 

> - Section
> 21.1.2: Use of (D)TLS doesn’t help against dictionary attacks much, since
> presumably there’s low entropy in usernames and passwords alike. Thus, I
> question whether this is a “stronger” mitigation. 

The section only discusses "offline" dictionary attack, How is offline dictionary attack possible with (D)TLS ?

>- Section 12.1.6: “username”
> and “realm” are not considered sensitive? They seem sensitive to me. - As an
> extension, it seems possible to improve on what’s in STUN. For example, it
> may be worthwhile, here or elsewhere, to update STUN’s long term
> credential key derivation process (MD5(username + realm + password)) to
> something a bit more modern. This is quite likely out of scope, though in the
> context of client authentication it seems worth mentioning that TURN is
> limited to the mechanisms provided by STUN.

As mentioned previously, username may not be the end-user real identity and username can be anonymized.   

> 
> Nits and other comments:
> 
> - Section 2: “message-digest” is undefined in the Nonce definition.

Thanks, replaced "message-digest" with "server response"

> - Section 3: It’s probably worth citing RFC8446 as the recommended version
> of TLS. 

The draft says guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. RFC7525 says TLS 1.3 resolves the vulnerabilities found in previous TLS versions.

>- Section 3.4: It might be worth mentioning that use of (D)TLS for the
> client-to-server transport mitigates the need for Send and Data
> authentication.

https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-21.1.4 discusses this issue in detail. 

> - Section 3.4: What does “proper security” mean? 

Thanks, replaced "proper security" with "end-to-end security".

>- Figure 4: Adding another
> message exchange wherein a channel message is sent without a prior
> ChannelBind request would be useful to highlight this dependency and
> expected behavior from clients and servers. 

https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-12.6 explains that If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded.

> - Section 3.6: Another benefit of
> this user space design decision is use of (D)TLS links. -

Good point, updated line to say:
for example, to allow a TURN server to be integrated into a peer-to-peer application so that one peer can offer NAT traversal services to another peer and to use (D)TLS to secure the TURN connection.

 Section 5: Where did
> the 40 second request buffer timeout come from? 

It is coming from the STUN specification (see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.3.1) 

> Adding some details
> might help. - Section 6: “secure hash” is undefined, though presumably what
> is meant is a cryptographic hash with collision resistance. It would be good to
> clarify this requirement. 

Yes, replaced with " cryptographic hash". 

> - Section 7.4: What is the retry behavior if allocation
> requests timeout? 

The retry behavior is discussed as follows:

   o  (Request timed out): There is either a problem with the server, or
      a problem reaching the server with the chosen transport.  The
      client considers the current transaction as having failed but MAY
      choose to retry the Allocate request using a different transport
      (e.g., TCP instead of UDP).


>- Section 12.5: The STUN requirement for 4-byte
> alignment should be cited when discussing the TCP and TLS padding
> requirement. 

Done.

> - Section 15: Typo “DON’T FRAGMENT”.

Fixed.

Cheers,
-Tiru

> 
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram