Subject: Re: [tram] STUN Origin Security Considerations

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 2 Dec 2014 04:29:15 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Wednesday, November 19, 2014 6:55 AM
> To: [email-masked]
> Subject: [tram] STUN Origin Security Considerations
> 
> Hi all,
> 
> In the meeting, I promised to follow up on this with a note to the list.
> 
> Text in the current draft states the following:
> 
>     The STUN ORIGIN attribute also has privacy implications in that the
>     origin information is shared with a STUN or TURN server which
>     otherwise might not know this information.  This information could be
>     used to track usage of real-time communication services.  A STUN or
>     TURN server will always know the public IP address of each user, but
>     the ORIGIN attribute provides more information about which service or
>     provider is being used.  The particular STUN and TURN servers used
>     are selected by the real-time communications service provider (i.e.
>     the web provider for WebRTC or the SIP or XMPP service provider).  In
>     addition, they are usually also run by the same provider, or by a
>     trusted partner, especially for TURN.  However, a service or provider
>     using a public STUN server needs to recognize that the operator of
>     the public STUN server will learn the identity of the service or
>     provider through this extension.
> 
> The last three sentences give the impression that the privacy concern does
> not apply to TURN servers, only to STUN servers, because TURN servers are
> more likely to be run by the application provider or a trusted partner of the
> application provider. This might not be true for auto-discovered, public, and
> other types of untrusted 3rd party TURN servers. The draft refers to "public
> STUN server" privacy implications, but I think the language could be
> broadened to cover all untrusted 3rd party relay servers.
> 
> I propose the following minor modifications to the text, which I think clarify
> the intent. My changes are inclosed in [ ].
> 
>     The particular STUN and TURN servers used are [usually] selected by
>     the real-time communications provider ...
> 
>     However, a service or provider using an [untrusted third party] STUN
>     [or TURN] server needs to recognize that the operator of the
>     [third party] STUN [or TURN] server will learn the identity of the
>     service or provider through this extension.
> 
> Does this seem reasonable ?

Yes, draft-patil-tram-turn-serv-selection in the selection criteria discusses that client if discovers multiple TURN servers then it should prefer a TURN server whose authenticity can be ascertained.

-Tiru

> 
> --Brandon
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram