Subject: Re: [tram] draft-johnston-tram-stun-origin-00

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 14 Jan 2014 04:35:24 +0000

Hi Alan,

Please see inline [TR]

From: Alan Johnston [mailto:[email-masked]] 
Sent: Monday, January 13, 2014 9:53 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tram] draft-johnston-tram-stun-origin-00

Tiru,

Thanks for your comments - I'm glad you like the draft.  See below for a few comments and replies.

- Alan -

On Mon, Jan 13, 2014 at 7:27 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
I like the draft, it solves the multiple realm problem we were discussing in BEHAVE WG sometime back http://tools.ietf.org/html/draft-reddy-behave-turn-auth-04
 
   5.  Hosting multiple realms on a single IP address is challenging
       with TURN.  When a TURN server needs to send the REALM attribute
       in response to an unauthenticated request, it has no useful
       information for determining which realm it should send, except
       the source transport address of the TURN request.  Note this is a
       problem with multi-tenant scenarios only.  This may not be a
       problem when TURN server is located in enterprise premises.
 
My initial comments
 
1.  Section Security Considerations
 
Comment 1>  On-path attacker can do much more damage like modifying the payload, dropping the packet etc. The more interesting scenario would be passive attacker sniffing the on-wire packets and can thus determine the value in the ORIGIN header.

That is true.  A passive attacker sniffing a STUN packet would be able to determine the ORIGIN.  The passive attacker might also be able to sniff DNS and HTTP traffic which would provide the same information, unless, as we point out in the draft, HTTPS and DNSSEC are both used.

Comment 2>  DTLS could also solve the problem with the server_name extension defined RFC6066.
Is there need for ORIGIN STUN attribute if DTLS is used with server_name extension ?

I'll take a look at RFC 6066 and see if it solves the problem.  Is RFC 6066 widely implemented and used?

[TR] Yes

Comment 3>  ORIGN attribute would be typically used before long-term authentication has started. In what scenarios content of ORIGIN attribute will be integrity protected ?

The ORIGIN attribute will be present both before and after authentication, so after authentication it will be integrity protected by the MESSAGE-INTEGRITY attribute, right?

[TR] After authentication I don't see a need for including ORIGIN attribute.

2.  Section STUN usage
 
Rouge Client can include any domain to which STUN binding response would be received to defeat the purpose. The only way to solve the problem would be to use STUN Auth. Though STUN Auth is typically not used with Public STUN servers, but with STUN servers deployed in the Enterprise premises the situation could change.  http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.3.5 explains the use case of enterprise deploying STUN server.

Yes, ORIGIN doesn't replace authentication.  However, in the WebRTC case, it would require a rogue or hacked browser.  I think this draft helps solve that use case for enterprise users who are out on the public Internet.  An enterprise STUN server could use the attribute to determine which STUN requests from the public Internet it should respond to.
 
[TR] Ok
 
-Tiru.

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Friday, January 10, 2014 7:21 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [tram] draft-johnston-tram-stun-origin-00
 
Hi
I've been reviewing the draft http://www.ietf.org/mail-archive/web/tram/current/maillist.html .
The general idea definitely makes sense.
 
Large TURN servers may indeed need separate realms for separate groups of users. It would make the administration more structured. Also, the TURN server may provide different level of services for different realms. For example, the "front" TURN server may just redirect with 300 error different origins to different backend servers with different configurations.
One thing that I wish to be included into the draft would be the exact new STUN attribute value (section 2). Without that value, a test/proof of concept implementation cannot be done. I'd suggest a definition like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)
The value 0x802F is in comprehensive-optional range, and it is not taken (yet).
Thanks
Oleg
http://code.google.com/p/rfc5766-turn-server/