Re: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return

mDNS only helps to discover TURN service in the local network; client and TURN server still have to mutually authenticate each other using the existing long-term authentication mechanism.  Trusted pre-configuration is only required to validate the digital signature of the mDNS answer just like it’s done in DNSSEC but if client and TURN server mutually authenticate then digital signature for answers may not be required.

-Tiru

From: Benjamin Schwartz [mailto:bemasc@webrtc.org]
Sent: Wednesday, April 08, 2015 7:57 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; tram@ietf.org
Subject: Re: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return

If the TURN server's identity is discovered over mDNS, then how can the client authenticate the TURN server, except to prove that it's the same one advertised over mDNS?  Assuming mDNS is trivial to forge on a broadcast network, this does not seem like sufficient protection.  Maybe you are saying that the TURN server's "real identity" is configured by some other mechanism, and only its address is distributed by mDNS?

I'm not familiar with the interaction between mDNS and DNSSEC, or how this would help to identify trusted servers.  This seems like another case in which a trusted pre-configuration mechanism is still required.

On Wed, Apr 8, 2015 at 8:40 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com<mailto:tireddy@cisco.com>> wrote:
> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org<mailto:tram-bounces@ietf.org>] On Behalf Of Simon Perreault
> Sent: Wednesday, April 08, 2015 5:39 PM
> To: tram@ietf.org<mailto:tram@ietf.org>
> Subject: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return
>
> TRAMsters,
>
> I'd like to see some discussion on how this impacts the server-discovery
> draft. This part in particular...
>
> "endpoints MUST NOT implement a       configuration based on
> unauthenticated
> network multicast (e.g. mDNS)"
>
> ...seems at odds with what was decided in Dallas (i.e., define mDNS
> discovery).
>
> Thoughts?

Yes. After TURN server is discovered using mDNS, client must authenticate the TURN server to avoid some malicious host advertising that it offers TURN service. Further mDNS http://tools.ietf.org/html/rfc6762#section-21 also refers to using DNSSEC so that the client can ensure that the service is provided by a trusted participant and not a rouge participant.

-Tiru

>
> I see having a coherent story for return and server-discovery as somewhat
> required...
>
> Simon
>
> -------- Message transféré --------
> Sujet : Re: [rtcweb] draft-schwartz-rtcweb-return Date : Wed, 8 Apr 2015
> 00:58:29 +0000 De : Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>> Pour :
> rtcweb@ietf.org<mailto:rtcweb@ietf.org> <rtcweb@ietf.org<mailto:rtcweb@ietf.org>>
>
>
> > On Mar 26, 2015, at 9:20 AM, Cullen Jennings <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:
> >
> > I'd like to point out that the combination of ietf-tram-turn-server-discovery
> and draft-schwartz-rtcweb-return allow any network you are connected to
> more or less MITM your media and do things like rate limit it, generate
> analytics on who you are talking to, force your traffic through an
> intermediary that is in a  different legal jurisdiction and so on.
>
> We discussed this after the meeting and came up with a  way to resolve this
> concern. Benjamin has added some text to the -06 to that specifically
> addresses this issue
>
> http://www.ietf.org/rfcdiff?url1=draft-schwartz-rtcweb-return-05&url2=draft-
> schwartz-rtcweb-return-06
>
> This completely deals with the issue I raised and with that change I support
> adopting this as a WG document.
>
> After adoption, I think the WG should consider if any text is needed around
> the issue of TURN credentials. (If you run TURN with no credentials and an
> attacker can spoof the IP address in UDP packets, you can end up with the
> TURN servers in a nasty forwarding loop that allows an huge amplification
> factor for an attacker trying do DOS the turn servers - this is still possible
> with authentication but you know who to blame. When TURN was first done
> with was one of the reason TURN requires auth and STUN does not).
> However, I believe this issue can solved and should not block adopting the
> draft. )
>
> Cullen
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org<mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org<mailto:tram@ietf.org>
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org<mailto:tram@ietf.org>
https://www.ietf.org/mailman/listinfo/tram