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

From: "Karl Stahl" <[email-masked]>
Date: Mon, 3 Aug 2015 13:25:23 +0200

BA > ”… this document it was not clear to me how it was intended”

I agree and have made comments (that were not considered in the -04 version since it came in parallel) at:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg14927.html 

one thing being that the RETURN draft should be referenced.

In draft-ietf-rtcweb-return-00.txt the browser usage of a network provided TURN server is made clear and that it effectively parallels the default gateway path (that is to be avoided for real-time traffic when blocking or don’t give quality). And I stated: We need this draft implemented in WebRTC browsers as soon as possible, so we can get good WebRTC in difficult places (for firewall traversal and for quality).

I also commented on this thread,

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

ending up in the following summary:

... the anycast route to the server should only be available to the inside (local, LAN side) of the default gateway (that a network provided turn server parallels to get a good path for real-time traffic)

...there seem to be a misunderstanding of why we need discovery of a network provided turn server

The very purpose of discovery is to find the turn server offered to users of the particular network segment that it servs.

Simply put, that Cisco turn server should not authenticate Allocate request from inside users. No credentials needed!

... A network provided turn server has the same trust level as the default gateway it is paralleling, so no problem is introduced. 

I think clarification of the above must go into the discovery-draft.

In addition, the following should be added in relation to “configuration” and “credentials/authentication” :

For use cases where manual configuration is wanted and possible, maybe at an enterprise LAN, and for example 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 provided to the users. However, for such (unusual) use cases, it is probably easier to also provide the IP address of the TURN server, so discovery according to this document will not be used.

Regarding the DNS discovery methods outlined (and much discussed), it must be made clear, that they only shall be deployed in local DNS, only made available to the users that the TURN server is intended to serve and made available for. For a WebRTC browser, I think the Anycast, and possible the DHCP based methods are sufficient to use (thus not using any of the DNS methods). 

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

We shall notice that the TTL limitation is for the following purpose (anycast in itself of course only routes to the deployed turn server):

From:  http://www.ietf.org/mail-archive/web/tram/current/msg01742.html 

Is the concern instead that, from a network segments NOT having a properly configured and advertised network provided turn server, the very discovery process of sending an Allocate request to the anycast address, may reveal things to the outside or that a far away turn server (not paralleling any of the default gateways that has to be passed) will be used?
 
If so, the discovery draft under 9. Security Considerations, 9.3 Anycast 
Suggests "...set an IP TTL on their TURN requests that limits how far they can travel..."
 
Maybe this TTL setting can be guided by a trace route before, so that the TURN requests intended for a network provided turn server never reaches the public internet.
 
Is there such improvement of the anycast discovery process to be made?
 
/Karl

Från: tram [mailto:[email-masked]] För Bernard Aboba
Skickat: den 30 juli 2015 20:36
Till: Benjamin Schwartz
Kopia: [email-masked]
Ämne: Re: [tram] Review of draft-ietf-tram-turn-server-discovery-04

Benjamin said: 

"In WebRTC scenarios, RETURN specifies the correct handling of autodiscovered TURN servers.  "

[BA] It seems like RETURN could be relevant beyond Web-based scenarios (e.g. use in a mobile application).  But the draft doesn't mention RETURN at all.  

On Thu, Jul 30, 2015 at 11:31 AM, Benjamin Schwartz <[email-masked]> wrote:

On Thu, Jul 30, 2015 at 2:23 PM, Bernard Aboba <[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" ?

In WebRTC scenarios, RETURN specifies the correct handling of autodiscovered TURN servers.  The conclusion, roughly, is that JS-specified TURN servers and autodiscovered TURN servers are configured independently, and under various conditions the client may use both simultaneously, neither, or either one of the two.

I agree that the autodiscovery draft could be clearer about its interaction with WebRTC.

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

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

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. 

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

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.   

   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.   

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.  Also, the

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

domain).  

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. 

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 25 Aug 2015 01:44:46 +0000

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:

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

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"

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.

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.

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

[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

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

Section 9.3

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: Fri, 28 Aug 2015 12:46:40 +0200

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

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

[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: Fri, 28 Aug 2015 16:42:08 +0000

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

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

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

Specific comments:

Section 3

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

Section 9.2

  Also, the

Section 9.3

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: Mon, 31 Aug 2015 22:12:43 +0200

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] <mailto:[email-masked]> 
Cc: 'Bernard Aboba'
Subject: Re: [tram] FW: Review of draft-ietf-tram-turn-server-discovery-04

Hi Prashanth,

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.

/Karl

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:

      server's public key.

Specific comments: 

Section 3

Section 9.2

   servers.

  Also, the

domain).  

Section 9.3

-Prashanth