Re: [tram] signature based 3rd party scheme

> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Wednesday, April 29, 2015 2:24 AM
> To: tram@ietf.org
> Subject: [tram] signature based 3rd party scheme
> 
> 
> Hiya,
> 
> As part of my discuss [1] on draft-ietf-tram-turn-third-party-authz [2] I
> questioned why the WG have only defined a shared secret based scheme
> (with the secret between the TURN and WebRTC servers in that case). That
> requires pre-arrangement between WebRTC servers and TURN servers, which
> I think isn't always going to be easily done, and seems to me to assume
> certain business models and to be more suited for larger providers (for both
> servers) and less suited for what may well be a fairly substantial long tail of
> WebRTC and TURN servers. Note that I am not saying that the scheme from
> [2] is broken but that it has some properties that are less desirable and the
> DISCUSS point is to ask if the WG had looked at other possibilities. I'm told
> that the WG have not, so this mail is to ask the question in more detail.
> (When this thread has run it's course, or if the response to this is crickets, I'll
> clear that discuss point.)
> 
> I could envisage a signature based scheme, where the WebRTC server
> digitally signs some form of token that the browser can then present to the
> TURN server and that the TURN server can then validate (if it wants to). That
> could provide accountability and be a sufficient counter against abuse of the
> TURN server's bandwidth. I could actually see lots of potential usage models
> that could be built on such a scheme, some involving someone billing
> someone and others not. But the main point is that the would be no a-priori
> need for co-ordination between the TURN server and the WebRTC server
> ahead of time.
> 
> The above is obviously just a sketch and a real scheme derived from that
> would not have otherwise identical properties to [2] but should I think be
> something that could be used and more easily deployed than the scheme
> from [2].
> 
> So - would such a scheme be attractive to the WG, and if so, then what's the
> right course of action wrt [2]? (That could be to push [2] along and start
> another draft on a signature based scheme, or to just push [2[ along, or
> something else.)

Passive attacks could occur in TURN due to lack of integrity protection. For example, a passive attacker could monitor Allocate request/response between the client and TURN server and make a Refresh request with a requested lifetime of 0 to delete the allocation. Message integrity of TURN messages ensures that passive attacker cannot spoof TURN messages. TURN client and server can compute message integrity using [2], but it is not possible with the signature based scheme. However signature scheme could work if (D)TLS is used b/w TURN client and server. 

-Tiru

> 
> Thanks,
> S.
> 
> PS: I'm not subscribed to this list, so would appreciate if you'd cc me on
> responses.
> 
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-
> authz/ballot/#stephen-farrell
> [2] https://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-15
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram