Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

On 10/05/15 18:19, Simon Perreault wrote:
> I don't follow. If the browser lies, then authentication will fail.
> Where's the problem?
> 

So let's say that a TURN server works on behalf of two
"tenant" services, S1 and S2 (legacy-SIP or WebRTC doesn't
matter for this point).

S1 are mean and charge the end user per byte/second and
when the TURN server is working on behalf of S1 then the
TURN server will do loads of accounting that'll eventually
turn into billing from S1 to the user at the UA.

S2 however are rich new Internet kids and offer calling
for nothing - they just use some of their vast advertising
revenue to pay the TURN server operator a big pile of cash
and the end user never has to pay, because S2 make money
elsewhere.

As a user, I can have accounts with both, and can authenticate
to the TURN server as either. (I'm not saying that is good
but it is what you've told me I think.)

I will of course always assert that the "origin" for all of
my calls is S2 and authenticate with those credentials, even
when I'm making a call that is setup by S1 and that properly
ought to be billed that way. (And such a call can be to a
destination that is simply not reachable via S2's signalling
of course.)

The fact that this origin is used by the TURN server to
pick between those and that there is no binding between
that and the in-progress call enables me to succeed when I
try the age-old trick of getting calls for nothing.

And similar issues will arise if there is any differentiation
between what the STUN/TURN server does for any of it's
multiple tenants. (Logically, that would seem to imply that
the TURN server has to offer the exact same service to all
tenants as a result of this protocol feature/flaw, which
would presumably de-value all multi-tenant features to the
extent they'd just die out. But then logic doesn't always
rule I guess:-)

Can you tell me what in the current proposal (or the underlying
context, and hence perhaps properly not documented here) means
that the above is a non-issue? Or where else am I going wrong?

Cheers,
S.

PS: It's obvious I guess, but this isn't directly about the
privacy aspects of the draft, though any solutions would impinge
on the discussion of the privacy aspects of the draft and hence
on this overall discussion.