Re: [tram] signature based 3rd party scheme

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

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Wednesday, April 29, 2015 2:38 PM
> To: Tirumaleswar Reddy (tireddy); [e-mail]
> Subject: Re: [tram] signature based 3rd party scheme
> 
> 
> Hiya,
> 
> On 29/04/15 03:59, Tirumaleswar Reddy (tireddy) wrote:
> > 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.
> 
> Well, that'd be an active attack as the adversary is sending messages, but
> that's a minor point of terminology only.
> 
> > 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.
> 
> Yes, it is the case that [2] (the current draft) does provide a key to the
> browser and TURN server that can be used for that. Getting that key to the
> TURN server however, requires the pre-arrangement stuff, including TLS
> client auth between the TURN server and WebRTC server (with the TURN
> server as TLS client), and doing that requires the TURN server to have signed
> up with a CA that the WebRTC server can verify, so that really is quite a lot
> of organisation (essentially a whole new thing like, but smaller than, the
> Web PKI just for TURN servers to authenticate themselves to the WebRTC
> servers).

TURN server and AS could be in the same administrative domain and pre-arrangement is simple in this case. The other deployment scenario is WebRTC service provider has tie-up with TURN service provider to use its service; pre-arrangement helps accounting and in future support for token introspection https://tools.ietf.org/html/draft-ietf-oauth-introspection-08.
(There is no WG consensus yet if token introspection is required)

> 
> So what you consider a downside may actually be another advantage of a
> signature based scheme - if you need to worry about attacks on the STUN
> protocol, then you can choose how you handle that "locally" (between the
> browser and TURN server, e.g. using DTLS as you suggest) and not have to
> depend on the establishment of yet another Web PKI equivalent.

Yes and in this scenario WebRTC server must force the client to pick DTLS.

-Tiru
> 
> Cheers,
> S.