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

"Konda, Tirumaleswar Reddy" <> Mon, 08 July 2019 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CD0A1201EC; Mon, 8 Jul 2019 07:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 483ZFm5wqlbF; Mon, 8 Jul 2019 07:18:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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;; 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 (unknown []) by 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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:28 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 8 Jul 2019 08:18:28 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:26 -0600
Received: from ( by ( 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 ([fe80::570:2208:75c2:5f17]) by ([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" <>
To: Christopher Wood <>, "" <>
CC: "" <>, "" <>, "" <>
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: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
authentication-results: spf=none (sender IP is );
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( 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-Transport-CrossTenantHeadersStamped: DM5PR16MB1403
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: : core <6585> : inlines <7115> : streams <1826746> : uri <2865133>
Archived-At: <>
Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> On Behalf Of Christopher Wood via
> Datatracker
> Sent: Monday, July 8, 2019 1:59 AM
> To:
> Cc:;;
> 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  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 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 

> 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, It could be an ephemeral and unique key identifier. Further, username can be anonymized (please see   
SOFTWARE and FINGERPRINT attributes are defined in the STUN specification, see 

- 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 

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

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


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



> _______________________________________________
> tram mailing list