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

[Stephen Farrell <[e-mail]>]

On 12/05/15 17:59, Simon Perreault wrote:
> Le 2015-05-12 12:41, Stephen Farrell a écrit :
>>> In the case where a single entity controls the authentication databases
>>> for all tenants of a single server, you're right. However, that
>>> condition does not hold in general. That is, we really do need to
>>> properly handle username collisions across realms.
>>
>> Sorry, I'm really not getting that. It is not a name for
>> a person, at least in WebRTC, right? It is some name
>> agreed between the WebRTC JS code and the TURN server. And
>> I'd hope it ought change frequently if it matters at all
>> or else it'll be scraped from the JS (or debug tooling).
> 
> What you say is true for WebRTC. A REST API for obtaining ephemeral
> usernames was even proposed:
> https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00
> 
> For SIP, however, usernames are not ephemeral, are not easily changed,
> and, depending on what client provisioning allows, are often constrained
> to be identical to the SIP username, while the realm is often
> constrained to be identical to the SIP domain name. WebRTC front-ends to
> SIP infrastructure could also have the same constraints.

Hmm. Wouldn't addressing that issue (same protocol field is
sometimes based on human memorable secrets and sometimes
now) have been a fine thing for the tram wg to have done. Is
that being addressed by the WG, other than via the oauth
approach?

S.

> 
>>> I'd appreciate if we could recognize that there is a problem with
>>> current practice, 
>>
>> I believe I did that already.
> 
> Sorry, I understood your last email as suggesting that username hacks
> made ORIGIN unnecessary.
> 
>>> 1) Are those concerns identical or different from those applying to,
>>> e.g., the Host HTTP header, or the SNI TLS extension? If they're
>>> different, how are they different?
>>
>> They may or may not be different but doing something better also
>> may or may not be more tractable. And the world has changed since
>> e.g. SNI was defined. (There is also desire to hide SNI in the
>> TLS 1.3 handshake if possible. We don't know if it will be possible
>> or not but the desire is there and is real.)
> 
> I'm all for discussing something better, but at the moment I don't know
> what that could be... Maybe it is obvious to security folks, but it is
> not to me!
> 
>>> 2) Is there a proposal that could fix the privacy issue? So far I've
>>> seen IESG members pointing out the issue, authors acknowledging the
>>> issue, but no discussion of solutions.
>>
>> From my POV, that is the discussion we are having and that is not
>> yet done.
> 
> Ok, I'm happy to continue then! :)
> 
> Simon
>