Subject: Secdir last call review of draft-ietf-tram-turnbis-27

From: Christopher Wood via Datatracker <[email-masked]>
Date: Sun, 07 Jul 2019 13:28:58 -0700

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? - 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? - 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. - 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. - Section 3 could also benefit from discussion
about cleartext versus encryption transports between clients and servers.
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. - 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? 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. - 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? 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.) - 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. - 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.

Nits and other comments:

- Section 2: “message-digest” is undefined in the Nonce definition.
- Section 3: It’s probably worth citing RFC8446 as the recommended version of
TLS. - 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.
- Section 3.4: What does “proper security” mean? - 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. - Section 3.6: Another benefit of this user space design
decision is use of (D)TLS links. - Section 5: Where did the 40 second request
buffer timeout come from? 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. -
Section 7.4: What is the retry behavior if allocation requests timeout? -
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”.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 8 Jul 2019 14:18:26 +0000

Hi Christopher,

Thanks for the detailed review. Please see inline

> -----Original Message-----
> From: tram <[email-masked]> On Behalf Of Christopher Wood via
> Datatracker
> Sent: Monday, July 8, 2019 1:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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.
> 
> 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.
> 
> 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:
> 
> 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
> 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”
> 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.   

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Jul 2019 15:30:45 -0500

Chris, thanks for the review.  Some more questions/comments inline as I
prepare to ballot on this document...

> discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis]

That helps, but it would still be nice to give some indication of what
certificate  PKI(s) are expected to be used.  Is anything other than the
Web PKI under consideration?

>       TURN messages to the server.

Is the editor's copy available for viewing somewhere?  It would be good to
see this (and other changes) in context.

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

There's not much discussion about potential information  leakage via (e.g.)
USERNAME/USERHASH, and really just a claim that the peer address is the
"primary protocol content".

> SOFTWARE and FINGERPRINT attributes are defined in the STUN specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21. 

These mechanisms  are partial mitigations but can still be susceptible to
cross-connection correlation attacks.

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

At least the latter seems to give some indication that many other users are
using the server at the  time (so that it's overloaded), though not
information about *which* users that is.

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

Where is this specified?

Thanks,

Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 10 Jul 2019 12:40:37 +0000

Hi Ben,

Thanks for the review. Please see inline.

> From: Benjamin Kaduk <[email-masked]>
> Sent: Wednesday, July 10, 2019 2:01 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Christopher Wood <[email-masked]>; [email-masked]; draft-ietf-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [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.
> > >
> > > 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.
> > >
> > > 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
> > 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]
> 
> That helps, but it would still be nice to give some indication of what certificate
> PKI(s) are expected to be used.  Is anything other than the Web PKI under
> consideration ?

No. Please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3, It discusses to verify the certificate path and identity of the server.

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

Yes, Please see https://github.com/tireddy2/TURNbis 

> > > 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.
> >
> > > discussion about cleartext versus encryption transports between
> > >clients and  servers.
> >

Agreed, added the following paragraph :

If the TURN client and server use the STUN Extension for Third-Party Authorization [RFC7635], the username does not reveal the
real user's identity, the USERNAME attribute carries an ephemeral and unique key identifier, and the key identifier can change per call.
If the TURN client and server use the STUN long-term credential mechanism and the username reveals the
real user's identity, the client need to either use (D)TLS transport between the client and the server or use 
the USERHASH attribute instead of the USERNAME attribute to anonynmize the username.

> > > 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.
> 
> These mechanisms  are partial mitigations but can still be susceptible to cross-
> connection correlation attacks.

The use of FINGERPRINT is not mandatory, the TURN client and server may include the FINGERPRINT attribute.  Note that ICE (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT attribute. Added the following line for SOFTWARE attribute (TURNbis is using the same behavior defined in RFC5766 to use SOFTWARE attribute)  :

SOFWATE attribute can reveal the specific software version of the TURN client and server to eavesdropper and it might possibly allow attacks against vulnerable software that is known to contain security holes. If it is important to prevent an eavesdropper from learning the software version, TURN can be run over (D)TLS.

> > > 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?
> >
> > > 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.
> 
> using the server at the  time (so that it's overloaded), though not information
> about *which* users that is.

Yes, similar to 503 HTTP error response.

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

It is specified in the last paragraph of https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10 

<snip>
If the client has been redirected to a
server to which it has already sent this request within the last five
minutes, it MUST ignore the redirection and consider the transaction
to have failed.  This prevents infinite ping-ponging between servers
in case of redirection loops.
</snip>

Cheers,
-Tiru

> > > (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.
> >
> > > 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.
> >
> > > - 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-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.
> >
> > 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
> > 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.
> >
> > > - Section 7.4: What is the retry behavior if allocation requests
> > > timeout?
> >
> > >- Section 12.5: The STUN requirement for 4-byte  alignment should be
> > >cited when discussing the TCP and TLS padding  requirement.
> >
> > Done.
> >

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 11 Jul 2019 15:27:50 -0700

Hi Tiru,

On Wed, Jul 10, 2019, at 5:41 AM, Konda, Tirumaleswar Reddy wrote:
> No. Please see 
> https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3, 
> It discusses to verify the certificate path and identity of the server.

Perhaps it would be good to explicitly say this in the document?

> Yes, Please see https://github.com/tireddy2/TURNbis 

Thanks!

> > "primary protocol content".

+1 to Ben's concern, which echoes my own.

> If the TURN client and server use the STUN Extension for Third-Party 
> Authorization [RFC7635], the username does not reveal the
> real user's identity, the USERNAME attribute carries an ephemeral and 
> unique key identifier, and the key identifier can change per call.

This is an improvement -- thanks! Should use of (D)TLS be mandated ("MUST" instead of "need to") when long-term credentials are used?

> > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21.

I realize they're defined elsewhere. My concern was that this draft seems to encourage sending them when perhaps that's not needed, i.e., as is the case for the SOFTWARE attribute.

> The use of FINGERPRINT is not mandatory, the TURN client and server may 
> include the FINGERPRINT attribute.  Note that ICE 
> (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT 
> attribute. Added the following line for SOFTWARE attribute (TURNbis is 
> using the same behavior defined in RFC5766 to use SOFTWARE attribute)  :
> 
> SOFWATE attribute can reveal the specific software version of the TURN 
> client and server to eavesdropper and it might possibly allow attacks 
> against vulnerable software that is known to contain security holes. If 
> it is important to prevent an eavesdropper from learning the software 
> version, TURN can be run over (D)TLS.

I'd replace "holes" with "vulnerabilities," and rewrite 

   "If  it is important to prevent an eavesdropper from learning the software  version, TURN can be run over (D)TLS."

as follows:

"TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text."

> > > Yes, UDP does not include a congestion control mechanism.

Right -- it might be good to mention this explicitly.

> > do not reveal information of which other users are using the TURN server.

Perhaps not which other *users* are using the TURN server, correct. It may leak other information though, and drawing HTTP 503 response code analogy would be helpful.

> It is specified in the last paragraph of 

Aha -- I missed that. Thanks!

Best,
Chris

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 12 Jul 2019 13:01:09 +0000

Hi Chris,

Please see inline 

> From: Christopher Wood <[email-masked]>
> Sent: Friday, July 12, 2019 3:58 AM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; Benjamin Kaduk
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > > Cc: Christopher Wood <[email-masked]>; [email-masked];
> > > draft-ietf- [email-masked]; [email-masked]; [email-masked]
> > > Chris, thanks for the review.  Some more questions/comments inline
> > > as I prepare to ballot on this document...
> > >
> > > > > From: tram <[email-masked]> On Behalf Of Christopher
> Wood
> > > > > via Datatracker
> > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > 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
> > > PKI(s) are expected to be used.  Is anything other than the Web PKI
> > > under consideration ?
> >
> > No. Please see

I added the following line:

[I-D.ietf-tram-stunbis].

> > > > 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,
> > > > > 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:
> > > >
> > > Is the editor's copy available for viewing somewhere?  It would be
> > > good to see this (and other changes) in context.
> >
> > > > > 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.
> > > >
> > > > >- 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.
> > >
> > > There's not much discussion about potential information  leakage via
> > > (e.g.) USERNAME/USERHASH, and really just a claim that the peer
> > > address is the "primary protocol content".
> 
> > Authorization [RFC7635], the username does not reveal the real user's
> > identity, the USERNAME attribute carries an ephemeral and unique key
> > identifier, and the key identifier can change per call.
> > If the TURN client and server use the STUN long-term credential
> > mechanism and the username reveals the real user's identity, the
> > client need to either use (D)TLS transport between the client and the
> > server or use the USERHASH attribute instead of the USERNAME attribute
> > to anonynmize the username.
> 
> This is an improvement -- thanks! Should use of (D)TLS be mandated
> ("MUST" instead of "need to") when long-term credentials are used?

I think you mean (D)TLS or USERHASH must be used, updated the line as follows:

If the TURN client and server use the STUN long-term credential mechanism and the username reveals the real user's identity, the client MUST either use the USERHASH attribute instead of the USERNAME attribute to anonynmize the username or use 
(D)TLS transport between the client and the server.

> 
> > > > > 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.
> > > >
> > > 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).
> I realize they're defined elsewhere. My concern was that this draft seems to
> encourage sending them when perhaps that's not needed, i.e., as is the case
> for the SOFTWARE attribute.

This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As you may know, TURN is used in the field for several years) and turnbis does not modify the behavior for backward compatibility. The use of FINGERPRINT is not mandatory, the draft says the TURN client and server may include the FINGERPRINT attribute.  

> 
> > >
> > > These mechanisms  are partial mitigations but can still be
> > > susceptible to cross- connection correlation attacks.
> >
> > The use of FINGERPRINT is not mandatory, the TURN client and server
> > may include the FINGERPRINT attribute.  Note that ICE
> > against vulnerable software that is known to contain security holes.
> > If it is important to prevent an eavesdropper from learning the
> > software version, TURN can be run over (D)TLS.
> 

Done.

> attribute in clear text."

We want to avoid double encryption of application data, and SOFTWARE attribute has been sent in clear text all these years in the field, and no attack has been detected based on SOFTWARE field. I can revise the text as follows:
If the software version is known to contain security vulnerabilities, TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text.

> > > > > there’s no allocation-based flow control mechanism between
> > > > > client and server beyond what’s provided by the transport protocol,
> right?
> > > >

Updated.

> 
> > > > > 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. -
> > > >
> Perhaps not which other *users* are using the TURN server, correct. It may
> leak other information though, and drawing HTTP 503 response code analogy
> would be helpful.

Added the following line:
Note that the error code values 486 and 508 indicate to a eavesdropper and the client that several other users are using the server at this time, similar to that of the HTTP error response code 503, but does not reveal any information about the users using the TURN server.

Cheers,
-Tiru

> 
> > > At least the latter seems to give some indication that many other
> > > users are using the server at the  time (so that it's overloaded),
> > > though not information about *which* users that is.
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Jul 2019 20:49:02 -0500

Hi Tiru,

Thanks for all the updates, including further downthread with Chris.
Just a couple notes inline...

> SOFWATE attribute can reveal the specific software version of the TURN client and server to eavesdropper and it might possibly allow attacks against vulnerable software that is known to contain sec…

The later suggestion was:

% We want to avoid double encryption of application data, and SOFTWARE attribute has  
% been sent in clear text all these years in the field, and no attack has been        
% detected based on SOFTWARE field. I can revise the text as follows:                 
% If the software version is known to contain security vulnerabilities, TURN SHOULD be
% run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text.

I think some of the concern is over the risk of so-called "zero-day"
exploits, where the attacker knows of a version-specific flaw but the
defenders do not (and have zero days notice to protect against it).  Such a
concern would suggest to avoid sending SOFTWARE over enencrypted transport
regardless of the state of known vulnerabilities, but in the end it is a
matter of local policy.

> in case of redirection loops.

Thanks for the pointer; as you saw in my ballot position I was quite
pressed for time this week and only was able to look at the diff.

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 13 Jul 2019 06:34:03 +0000

Hi Ben,

Please see inline

> Sent: Saturday, July 13, 2019 7:19 AM
> <[email-masked]>
> > No. Please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-
> 21#section-6.2.3, It discusses to verify the certificate path and identity of the
> server.
> >
> > >
> > > > >- Section 3.7: Could
> server or use the USERHASH attribute instead of the USERNAME attribute to
> anonynmize the username.
> >
> > >
> attribute. Added the following line for SOFTWARE attribute (TURNbis is using
> the same behavior defined in RFC5766 to use SOFTWARE attribute)  :
> >
> client and server to eavesdropper and it might possibly allow attacks against
> vulnerable software that is known to contain security holes. If it is important
> to prevent an eavesdropper from learning the software version, TURN can
> be run over (D)TLS.
> 
> % If the software version is known to contain security vulnerabilities, TURN
> SHOULD be % run over (D)TLS to prevent leaking the SOFTWARE attribute in
> clear text.
> 
> concern would suggest to avoid sending SOFTWARE over enencrypted
> transport regardless of the state of known vulnerabilities, but in the end it is
> a matter of local policy.

Agreed, fixing and releasing a patch will take some time and meanwhile the policy can be modified to use temporarily use (D)TLS.  I can add the following text:
If zero-day vulnerabilities are detected in the software version, the endpoint policy can be modified to mandate the use of (D)TLS till the patch is in place to fix the flaw.

> > If the client has been redirected to a server to which it has already
> > sent this request within the last five minutes, it MUST ignore the
> > redirection and consider the transaction to have failed.  This
> > prevents infinite ping-ponging between servers in case of redirection
> > loops.
> > </snip>
> 
> Thanks for the pointer; as you saw in my ballot position I was quite pressed
> for time this week and only was able to look at the diff.

No problem, thanks for help.

Cheers,
-Tiru