Subject: Re: [tram] signature based 3rd party scheme

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 29 Apr 2015 02:59:13 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, April 29, 2015 2:24 AM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Apr 2015 10:07:34 +0100

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).

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.

Cheers,
S.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 30 Apr 2015 13:14:53 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, April 29, 2015 2:38 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: Re: [tram] signature based 3rd party scheme
> 
> 
> Hiya,
> 
> > 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 14:21:44 +0100

On 30/04/15 14:14, Tirumaleswar Reddy (tireddy) wrote:
> 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 

I don't see that that is necessarily true. It depends on who
is accounting for what to whom.

> 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.

Again, that depends. If the TURN server is run by an enterprise then
it might just be fine with allowing calls setup by any WebRTC server
that can be held accountable or could use a white or block list of
WebRTC servers.

S.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 30 Apr 2015 16:36:28 +0000

> Sent: Thursday, April 30, 2015 6:52 PM
> I don't see that that is necessarily true. It depends on who is accounting for
> what to whom.

The WebRTC server could be accounting the resource server (TURN server) used by the client for the call.

> >>> 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.
> Again, that depends. If the TURN server is run by an enterprise then it might
> just be fine with allowing calls setup by any WebRTC server that can be held
> accountable or could use a white or block list of WebRTC servers.

Yes, third party authorization can be used by the TURN server in the Enterprise network to identify the WebRTC server.
 
-Tiru

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 17:42:17 +0100

On 30/04/15 17:36, Tirumaleswar Reddy (tireddy) wrote:
> Yes, third party authorization can be used by the TURN server in the
> Enterprise network to identify the WebRTC server.
> 

Indeed, if the current draft were the only way to do this then all
enterprises would have to pre-arrange things with all WebRTC servers.
IMO that won't work well, if at all.

A signature based scheme could be used in various ways, e.g. to
allow calls that don't consume much b/w regardless but to only
allow calls setup by whitelisted WebRTC servers when those calls
collectively consume a lot of b/w consumption.

The latter sounds like something that's much easier to deploy
to me and seems to meet some real use cases.

I really think the current wg draft is terribly limited in terms
of the kinds of use cases for which it'll work. I hope that the
wg consider those limitations seriously. (Or if you have already
please just point me at the archive/minutes that reflect that
discussion.)

S.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 30 Apr 2015 16:58:10 +0000

> Sent: Thursday, April 30, 2015 10:12 PM

No, pre-arrangement is not required with all WebRTC servers. 

> collectively consume a lot of b/w consumption.

The above problem can also be solved by the proposed mechanism in the draft and similar enterprise use case was discussed in IAB workshop sometime back https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_reddy.pdf.

-Tiru

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 18:06:46 +0100

> No, pre-arrangement is not required with all WebRTC servers. 

Sorry, how?

S.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 1 May 2015 03:56:09 +0000

> Sent: Thursday, April 30, 2015 10:37 PM

It is discussed in http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-15#section-6.1. If WebRTC server has pre-arrangement with the Enterprise network then client uses third party authorization with the TURN server in Enterprise network and when WebRTC server(s) do not have any pre-arrangement with the Enterprise network then the client uses first party authentication with the TURN server.
 
-Tiru