Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 1 Sep 2015 12:19:40 +0000

Yes, it applies to discovery of network provided TURN server. The "long-term credentials or third-party authorization" not only authenticates the user to the TURN server but also authenticate the TURN server to the user (i.e. perform mutual authentication) and provides integrity protection for  of TURN messages. (D)TLS prevents faked TURN messages that could be sent by an attacker.

(D)TLS also ensures that an attacker does not advertise TURN service and gets to learn the remote peer address with which the client
is exchanging traffic.

-Tiru
From: Karl Stahl [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 1:43 AM
To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); [email-masked]
Cc: 'Bernard Aboba'
Subject: SV: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Hi Tiru,

Even if your statement is correct - does it apply to this discovery of network provided TURN server draft?

The "long-term credentials or third-party authorization" you are mentioning are used to assure that only users of the web application (no other) consumes the TURN server resource. That is NOT a problem to solve in the this discovery draft. Here, the discovered TURN server is provided by the network admin for the purpose of being used by the users of his network. The TURN server resource is not available nor advertised to others, so it should simply be used (This TURN server does NOT need protection against unauthorized usage).

Did you read the thread ending at: https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1FmpOg

OR DO YOU MEAN...
that any of the discovery methods (which?) you are suggesting in the draft have a security flaw (which)? Is it worse to send the (encrypted) real-time traffic through the discovered TURN server than through the default gateway? Then explain why and how any Authentication/Validation/Authorization, (D)TLS or something else could help that and what it actually does and resolves.

OR DO YOU MEAN "the authentication talk" can/are creating a BETTER trust level when sending real-time traffic through the discovered TURN server than through the default gateway of the network? Then I still question whether such improvement belongs to this draft (the purpose of the discovered TURN server was to get real-time traffic firewall traversal or at better quality) , but I am interested to understand how you think you can achieve this and whether there are any bad consequences or limitations attached.

Otherwise, as I have pointed out, simply clarify what this draft is about, and remove the confusing parts.

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 28 augusti 2015 18:42
Till: Karl Stahl <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Kopia: 'Bernard Aboba' <[email-masked]<mailto:[email-masked]>>
Ämne: RE: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

If TURN client and TURN server are not using long-term credentials or third-party authorization then (D)TLS is the only way to authenticate the TURN server, and it also solves the problem of MIM attacker modifying TURN messages, passive attacker deleting existing allocations etc. (D)TLS for TURN is already defined in RFC 5766 and RFC 7350.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Friday, August 28, 2015 4:17 PM
To: Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Cc: 'Bernard Aboba'
Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Hi Prashanth,

What you propose below is in no way acceptable, and adds to, rather than remedies the confusion this draft is introducing in its current form.

Please understand that:

1) Checking the validity of a certificate does not in itself or automatically help "Security and privacy are important considerations" as you state in your answer in the previous email. The security improvement we get by accessing a website with https rather than http is (in addition to the encryption) ONLY that the user can be sure of that when he surfs to www.goodcompany.com<http://www.goodcompany.com>, he can be sure that what he gets in his browser actually comes from the owner of the goodcompany.com domain name.

2)  In the context of WebRTC usage, you do not achieve anything by checking a certificate for a discovered TURN server. The validation in itself does not guarantee anything about whether the TURN server is good or bad or evil. Further, the certificate for the TURN server will not even be presented to the user to give him the (impossible) task of judging whether to trust a transport, based on the domain name validation (if that is the thought behind introducing this).

3) If you don't have another purpose with this draft than (copied from the previous email):
"The purpose of discovery of a network provided TURN server is to find a TURN server offered by a network provider or a network admin, to be used for real-time traffic by the users on that network segment."
please also understand (copied from the previous email):
"An advertised network provided TURN server, shall simply be interpreted as an advice to use the TURN server path for real-time traffic, instead of using the default gateway path. The level of trust is the same for both paths (since both the default gateway and the TURN server are offered and arranged by the network provider). A sealed configuration (as outlined in draft-ietf-rtcweb-return) can be arranged by the network provider by blocking STUN packets in the default gateway."
It not up to this discovery draft to specify or to "try to invent" higher trust levels.

And it must not be up to this draft to recommend about the transport (you are here suggesting (D)TLS), and especially not with a motivation that does not achieve anything positive in the context of WebRTC usage. For WebRTC, there are the RTCWEB WG's TRANSPORT, RETURN and possible other documents where transports are being specified.

/Karl

PS For further details, see previous email on the "last call on this draft: draft-ietf-tram-turn-server-discovery-03" thread

Från: tram [mailto:[email-masked]] För Prashanth Patil (praspati)
Skickat: den 25 augusti 2015 03:45
Till: Bernard Aboba; [email-masked]<mailto:[email-masked]>
Ämne: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Hi Bernard,

On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

1. Overall, in reading this document it was not clear to me how it was intended
to be applied to WebRTC scenarios where a TURN server is configured in the JS.

* Does TURN server discovery apply in this case, or is the JS-specified TURN server considered "manual TURN configuration" ?

Yes, JS-specified TURN server should be considered as auto-configuration. We'll update the draft accordingly.

* Where IdP is used, is the local IdP identity considered to consitute a "domain name" per Section 4.1.2?

Is there a need to make this explicit? The text in the draft is intentionally generic to leave the decision up to the application:

"For a TURN client with an understanding of the protocol mechanics of calling applications, the client may wish to extract the domain name from its own identity"

2. In scenarios where TURN Server discovery does apply, what mechanisms are to be used to authenticate or authorize the discovered TURN Servers(s)?  Using a configured domain name seems like a potentially viable approach, but there are scenarios where that might not be configured, or might not be secure
(e.g. if the domain name were obtained from unauthenticated DHCP).

We plan to add the following, does it address some of your concerns:
TURN client can use the following techniques to validate a TURN server:

   o  For certificate-based authentication, this
      includes a pre-populated trust anchor store [rfc6024] that allows the
      the TURN client to perform path validation for the server certificate obtained
      during the (D)TLS handshake. The client MUST use the rules and guidelines given in section 6 of
      [RFC6125] to validate the TURN server identity.

   o  For TURN servers that don't have a certificate trust chain
      (e.g., because they are on a home network or a corporate network),
      the configured list of TURN servers can contain the Subject
      Public Key Info (SPKI) fingerprint of the TURN servers. The public key is
      used for the same reasons HTTP pinning [RFC7469] uses the public key.

   o  For raw public key-based authentication as defined in [RFC7250], this
      includes either the TURN server's public key or the hash of the
      server's public key.

Using the browser's configured trust anchor(s) doesn't seem like a good idea, given that it would only be as secure as the least-secure trust anchor.

Isn't that true with any server the client tries to validate using certificates?

Specific comments:

Section 3

   1.  Local Configuration : Local or manual TURN configuration (i.e.,
       TURN servers configured at the system level) should be tried
       first, as it may be an explicit preferred choice of a user.

[BA] Would TURN servers specified within a WebRTC JS application be considered "local or manual" in this context?

Also, shouldn't a configured domain name (Section 4.1.2) be considered part of "local TURN configuration"?

Yes, configured domain name can be considered as local or auto-configuration.

IMHO, the configured domain name not only enables discovery as indicated
in Section 4.2, but also provides a mechanism for validation of the
TURN server discovered by other methods.

Correct. We'll update the draft to highlight this point.

   The document does not prescribe a strict order that a client must
   follow for discovery.  An implementation may choose to perform steps
   2,3 and 4 in parallel for discovery OR choose to follow any desired
   order and stop the discovery procedure if a mechanism succeeds.

[BA] I am not sure I buy this.  It is already stated that "local or manual" configuration should be tried first, and I would considered a configured domain name to be part of this, which would imply attempting 2 first if that exists.

Good point. A client should be able to perform discovery on all in parallel (or in any order of choice), including manual/auto configuration.

Section 9.2

   For mDNS, in addition to what has been described above, a principal
   security threat is a security threat inherent to IP multicast routing
   and any application that runs on it.  A rogue system can advertise
   that it is a TURN server.  Discovery of such rogue systems as TURN
   servers, in itself, is not a security threat if there is a means for
   the TURN client to authenticate and authorize the discovered TURN
   servers.

[BA] In scenarios in which mDNS would be used, there typically will not be a
means for the TURN client to authentication and authorize the discovered
TURN server. For example, a home router with a built-in TURN server is
not likely to have a certificate chaining to a trust anchor.

If discovered in a local n/w, a client can be explicitly configured with the fingerprint of the server.

  Also, the
mDNS is not compatible with DNSSEC (e.g. there is no signer for the .local
domain).

Same as above. A client, if configured with a fingerprint, could validate the server.

Section 9.3

   Sensitive clients that do not wish to leak information about their
   presence can set an IP TTL on their TURN requests that limits how far
   they can travel into the public Internet.

[BA] This seems like a crude tool at best.  If the goal is to provide privacy,
wouldn't use of encryption make more sense?  This could include DNS privacy,
encryption of TURN traffic, etc.

TURN encryption wouldn't be possible because the client is not aware of the TURN server it is trying to connect. The above is only a recommendation if a client is concerned with anycast going out of a desired boundary.

-Prashanth

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 2 Sep 2015 09:53:59 +0200

> Yes, it applies to discovery of network provided TURN server. 

!??? Just what do you mean?

Have you missed:

http://www.ietf.org/mail-archive/web/tram/current/msg01806.html  ?

“The purpose of discovery of a network provided TURN server is to find a
TURN server offered by a network provider or a network admin, to be used for
real-time traffic by the users on that network segment. For WebRTC usage
“everywhere you can surf”, such TURN servers must be used without requiring
users to have credentials for responding to authentication challenges.
Network provided TURN servers must therefore be configured to not challenge
allocation requests from the network segment that they serve and the TURN
server should only be available to and advertised to those users. 

An advertised network provided TURN server, shall simply be interpreted as
an advice to use the TURN server path for real-time traffic, instead of
using the default gateway path. The level of trust is the same for both
paths (since both the default gateway and the TURN server are offered and
arranged by the network provider). A sealed configuration (as outlined in
draft-ietf-rtcweb-return) can be arranged by the network provider by
blocking STUN packets in the default gateway.

For use cases where individual user configuration is wanted and possible,
maybe at an enterprise LAN where not all users should be allowed to use the
TURN server, the TURN server must be configured to authenticate the users,
and credentials then be given to the users. However, for such (unusual) use
cases, it is probably easier and better to also give the IP address of the
TURN server itself to the users, so discovery according to this document
would then not be used.”

> The “long-term credentials or third-party authorization“ not only
authenticates the user* to the TURN server but also authenticate the TURN
server to the user* (i.e. perform mutual authentication) 

--- These methods are not (cannot be) used for network provided turn
servers, to be used by all users of that network segment!

> (D)TLS prevents faked TURN messages that could be sent by an attacker.

--- All users on the specific network segment can send anything to any
discovered TURN server on that network segment – (D)TLS or not!

> (D)TLS also ensures that an attacker does not advertise TURN service 

--- Nothing is hindering an attacker’s TURN server from having a valid
certificate.

Nothing achieved! Clarify this discovery draft instead of introducing these
kind of things.

/Karl

PS

* This is also wrong; the “authentication is” between the web application
(that hands credentials to the user) and the TURN server, NOT “to the user”

And typically, the user does not have to use that TURN server either, if
another path for the real-time traffic is available. 

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 1 september 2015 14:20
Till: Karl Stahl; Prashanth Patil (praspati); [email-masked]
Kopia: 'Bernard Aboba'
Ämne: RE: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Yes, it applies to discovery of network provided TURN server. The “long-term
credentials or third-party authorization“ not only authenticates the user to
the TURN server but also authenticate the TURN server to the user (i.e.
perform mutual authentication) and provides integrity protection for  of
TURN messages. (D)TLS prevents faked TURN messages that could be sent by an
attacker.

(D)TLS also ensures that an attacker does not advertise TURN service and
gets to learn the remote peer address with which the client

is exchanging traffic. 

-Tiru

Hi Tiru,

Even if your statement is correct – does it apply to this discovery of
network provided TURN server draft?

The “long-term credentials or third-party authorization“ you are mentioning
are used to assure that only users of the web application (no other)
consumes the TURN server resource. That is NOT a problem to solve in the
this discovery draft. Here, the discovered TURN server is provided by the
network admin for the purpose of being used by the users of his network. The
TURN server resource is not available nor advertised to others, so it should
simply be used (This TURN server does NOT need protection against
unauthorized usage).

Did you read the thread ending at:
https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1FmpOg

OR DO YOU MEAN…

that any of the discovery methods (which?) you are suggesting in the draft
have a security flaw (which)? Is it worse to send the (encrypted) real-time
traffic through the discovered TURN server than through the default gateway?
Then explain why and how any Authentication/Validation/Authorization, (D)TLS
or something else could help that and what it actually does and resolves.

OR DO YOU MEAN “the authentication talk” can/are creating a BETTER trust
level when sending real-time traffic through the discovered TURN server than
through the default gateway of the network? Then I still question whether
such improvement belongs to this draft (the purpose of the discovered TURN
server was to get real-time traffic firewall traversal or at better quality)
, but I am interested to understand how you think you can achieve this and
whether there are any bad consequences or limitations attached.   

Otherwise, as I have pointed out, simply clarify what this draft is about,
and remove the confusing parts.

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 28 augusti 2015 18:42
Till: Karl Stahl <[email-masked]>; Prashanth Patil (praspati)
<[email-masked]>; [email-masked]
Kopia: 'Bernard Aboba' <[email-masked]>
Ämne: RE: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

If TURN client and TURN server are not using long-term credentials or
third-party authorization then (D)TLS is the only way to authenticate the
TURN server, and it also solves the problem of MIM attacker modifying TURN
messages, passive attacker deleting existing allocations etc. (D)TLS for
TURN is already defined in RFC 5766 and RFC 7350.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Friday, August 28, 2015 4:17 PM
To: Prashanth Patil (praspati); [email-masked]
Cc: 'Bernard Aboba'
Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Hi Prashanth,

What you propose below is in no way acceptable, and adds to, rather than
remedies the confusion this draft is introducing in its current form.

Please understand that:

1) Checking the validity of a certificate does not in itself or
automatically help “Security and privacy are important considerations” as
you state in your answer in the previous email. The security improvement we
get by accessing a website with https rather than http is (in addition to
the encryption) ONLY that the user can be sure of that when he surfs to
www.goodcompany.com, he can be sure that what he gets in his browser
actually comes from the owner of the goodcompany.com domain name.

2)  In the context of WebRTC usage, you do not achieve anything by checking
a certificate for a discovered TURN server. The validation in itself does
not guarantee anything about whether the TURN server is good or bad or evil.
Further, the certificate for the TURN server will not even be presented to
the user to give him the (impossible) task of judging whether to trust a
transport, based on the domain name validation (if that is the thought
behind introducing this). 

3) If you don’t have another purpose with this draft than (copied from the
previous email):

“The purpose of discovery of a network provided TURN server is to find a
TURN server offered by a network provider or a network admin, to be used for
real-time traffic by the users on that network segment.” 

“An advertised network provided TURN server, shall simply be interpreted as
an advice to use the TURN server path for real-time traffic, instead of
using the default gateway path. The level of trust is the same for both
paths (since both the default gateway and the TURN server are offered and
arranged by the network provider). A sealed configuration (as outlined in
draft-ietf-rtcweb-return) can be arranged by the network provider by
blocking STUN packets in the default gateway.”

It not up to this discovery draft to specify or to “try to invent” higher
trust levels. 

And it must not be up to this draft to recommend about the transport (you
are here suggesting (D)TLS), and especially not with a motivation that does
not achieve anything positive in the context of WebRTC usage. For WebRTC,
there are the RTCWEB WG’s TRANSPORT, RETURN and possible other documents
where transports are being specified.

/Karl

PS For further details, see previous email on the “last call on this draft:
draft-ietf-tram-turn-server-discovery-03” thread 

Från: tram [mailto:[email-masked]] För Prashanth Patil (praspati)
Skickat: den 25 augusti 2015 03:45
Till: Bernard Aboba; [email-masked]
Ämne: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Hi Bernard,

On 7/30/15, 11:23 AM, "tram on behalf of Bernard Aboba"
<[email-masked] on behalf of [email-masked]> wrote:

1. Overall, in reading this document it was not clear to me how it was
intended

to be applied to WebRTC scenarios where a TURN server is configured in the
JS. 

* Does TURN server discovery apply in this case, or is the JS-specified TURN
server considered "manual TURN configuration" ? 

Yes, JS-specified TURN server should be considered as auto-configuration.
We’ll update the draft accordingly.

* Where IdP is used, is the local IdP identity considered to consitute a
"domain name" per Section 4.1.2?  

Is there a need to make this explicit? The text in the draft is
intentionally generic to leave the decision up to the application:

"For a TURN client with an understanding of the protocol mechanics of
calling applications, the client may wish to extract the domain name from
its own identity"

2. In scenarios where TURN Server discovery does apply, what mechanisms are
to be used to authenticate or authorize the discovered TURN Servers(s)?
Using a configured domain name seems like a potentially viable approach, but
there are scenarios where that might not be configured, or might not be
secure

      the TURN client to perform path validation for the server certificate
obtained

      during the (D)TLS handshake. The client MUST use the rules and
guidelines given in section 6 of

      Public Key Info (SPKI) fingerprint of the TURN servers. The public key
is

      server's public key.

Using the browser's configured trust anchor(s) doesn't seem like a good
idea, given that it would only be as secure as the least-secure trust
anchor. 

Isn’t that true with any server the client tries to validate using
certificates?

Specific comments: 

Section 3

[BA] Would TURN servers specified within a WebRTC JS application be
considered "local or manual" in this context? 

Also, shouldn't a configured domain name (Section 4.1.2) be considered part
of "local TURN configuration"? 

Yes, configured domain name can be considered as local or
auto-configuration.

Correct. We’ll update the draft to highlight this point.

[BA] I am not sure I buy this.  It is already stated that "local or manual"
configuration should be tried first, and I would considered a configured
domain name to be part of this, which would imply attempting 2 first if that
exists.   

Good point. A client should be able to perform discovery on all in parallel
(or in any order of choice), including manual/auto configuration.

Section 9.2

   servers.

If discovered in a local n/w, a client can be explicitly configured with the
fingerprint of the server.

  Also, the

domain).  

Same as above. A client, if configured with a fingerprint, could validate
the server.

Section 9.3

[BA] This seems like a crude tool at best.  If the goal is to provide
privacy,

TURN encryption wouldn’t be possible because the client is not aware of the
TURN server it is trying to connect. The above is only a recommendation if a
client is concerned with anycast going out of a desired boundary.

-Prashanth

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 2 Sep 2015 12:17:34 +0000

Inline [TR]

> The "long-term credentials or third-party authorization" not only authenticates the user* to the TURN server but also authenticate the TURN server to the user* (i.e. perform mutual authentication) 
--- These methods are not (cannot be) used for network provided turn servers, to be used by all users of that network segment!

[TR] Why can't these methods be used by network provided turn servers ?
For example an Enterprise network may use both these methods and a SP deploying TURN servers may not enable any of these methods.

> (D)TLS prevents faked TURN messages that could be sent by an attacker.
--- All users on the specific network segment can send anything to any discovered TURN server on that network segment - (D)TLS or not!

[TR] Please explain how to handle the above attack without (D)TLS ?

> (D)TLS also ensures that an attacker does not advertise TURN service 
--- Nothing is hindering an attacker's TURN server from having a valid certificate.

[TR] It won't be part of trust store, I don't see a attack !

-Tiru

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 3 Sep 2015 16:23:02 +0200

Tiru,

Please read the introduction to draft-ietf-rtcweb-return-00.txt on what we
want to use network provided turn servers for. 

Those TURN servers are only available to the users on that specific network
segment and should be used for the real-time traffic of users on that
specific network segment, and have the same level of trust as if the
real-time traffic was sent through the default gateway.

This discovery draft shall specify usable methods for auto discovery of such
TURN servers.

The TURN servers should only be advertized to users on the network segment
they shall serve, and must be able to use without users having credentials
or doing other forms of authentication other than simply being on the
network.

The draft must be freed from confusing statements or recommendations like
the ones below.

Also, understand that there are things that you and this draft cannot
improve upon – like the general level of trust in using a certain access
network – That does not belong to an auto discovery draft!

See inline below.

/Karl

PS It may be good now to read and go through all the threads relating to
this draft -03 and -04, before again asking about these things

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 2 september 2015 14:18
Till: Karl Stahl; Prashanth Patil (praspati); [email-masked]
Kopia: 'Bernard Aboba'
Ämne: RE: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Inline [TR]

> The "long-term credentials or third-party authorization" not only

[Karl] The web application has no knowledge whatsoever about the network
provided turn servers.

Did you read the PS: 

For example an Enterprise network may use both these methods and a SP
deploying TURN servers may not enable any of these methods.

[Karl] If the network admin for some strange reason wants to give his users
credentials for using his TURN server (your mean?) he can also given the
users the ip address of the TURN server. We don’t need discovery for that
and we cannot clutter this recommendation with everything that CAN be done
- especially since it cannot be used generally and for the purpose of be
able to use WebRTC everywhere you can surf (and resolve the Firewall/NAT
traversal problem of real-time traffic).

--- All users on the specific network segment can send anything to any
discovered TURN server on that network segment - (D)TLS or not!

[Karl] You don’t handle that with (D)TLS either! On the same network segment
anyone can send anything to anyone else. That is what networks do!

[Karl] How do handle ”attacks” that everyone on that same network segment
can send anything to the default gateway? – You don’t “handle” such things!

> (D)TLS also ensures that an attacker does not advertise TURN service 

--- Nothing is hindering an attacker's TURN server from having a valid
certificate.

[Karl] So which CA is policing and having a register over all GOOD network
provided TURN servers in the universe, when you run around with your
smartphone and get WiFi here and there and want to use WebRTC applications?

Can we also have that magic for everything else you get by e.g. DHCP, so we
can know if we can use the network at all? But sh-t, how can we validate
anything without using the stuff we got via DHCP? Dead end - You must use
the network resources provided!

-Tiru