Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS)

[Stephen Farrell <[e-mail]>]

Hiya,

On 12/05/15 01:43, Alissa Cooper wrote:
>>> 
>>> if the client is lying, then the request will not be
>>> authenticated and it will be rejected - because the client's
>>> credentials will be incorrect.
>
> My question was about requests without authentication, as I said. I
> assume the origin is not used for authentication in that case, since
> authentication is not performed.
>

There's also this issue. If user credentials can collide over >1
"realm" (where authentication realm means in the HTTP basic/digest
sense) then those are almost certainly human memorable (why else
could they collide with non-negligible probability?) and in the
case of STUN/TURN and, in particular, WebRTC, setting up to use
human memorable credentials is just basically broken given that
the humans aren't actually logging in to the STUN/TURN server.

So I actually doubt the supposed security benefit even when the
web-origin is pre-emptively sent as an authentication realm (in
the HTTP basic/digest sense) just in case authentication with a
STUN/TURN server is later required. And pre-emptively sending
has the privacy downside that is recognised in the draft and
as previously noted.

Put another way: if a WebRTC server cannot arrange to use high
entropy credentials with a STUN/TURN server then perhaps we're
just promoting the wrong authentication scheme(s) and maybe
also prioritising avoiding the wrong code changes? (Some code
change being required in all cases.)

So if there is a real reason why there ought be a well designed
scheme for WebRTC with a non-negligible probability of credential
collision then I'd like to hear about it. (I'm not saying that's
impossible, but dumb old me can't figure it out;-)

Or perhaps we're conflating user authentication with other
protocol features (e.g. multi-tenant support) in a way that does
unnecessarily damage privacy for users?

S.