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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, September 01, 2015 1:43 AM
To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); [e-mail]
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:[e-mail]]
Skickat: den 28 augusti 2015 18:42
Till: Karl Stahl <[e-mail]<mailto:[e-mail]>>; Prashanth Patil (praspati) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Kopia: 'Bernard Aboba' <[e-mail]<mailto:[e-mail]>>
Ä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:[e-mail]] On Behalf Of Karl Stahl
Sent: Friday, August 28, 2015 4:17 PM
To: Prashanth Patil (praspati); [e-mail]<mailto:[e-mail]>
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:[e-mail]] För Prashanth Patil (praspati)
Skickat: den 25 augusti 2015 03:45
Till: Bernard Aboba; [e-mail]<mailto:[e-mail]>
Ä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" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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