Re: [Wish] Authentication for resource url

[Christer Holmberg <[e-mail]>]

Hi,

If the only thing you mandate to support is HTTP basic, would WHIP pass the security review?

Regards,

Christer

-----Original Message-----
From: Wish <[e-mail]> On Behalf Of Lorenzo Miniero
Sent: keskiviikko 15. syyskuuta 2021 13.19
To: Juliusz Chroboczek <[e-mail]>
Cc: WISH List <[e-mail]>
Subject: Re: [Wish] Authentication for resource url

On Wed, 15 Sep 2021 11:49:19 +0200
Juliusz Chroboczek <[e-mail]> wrote:

> >> To give an example of how this is done in production services: on 
> >> Twitch, once you log in, you go into account management, click on 
> >> the "Stream" tab, and copy a really long string of junk out of a 
> >> field labeled "Primary Stream Key." You paste this into your 
> >> broadcast client in a field usually named "Stream Key."
> 
> Just to be clear: I think token auth is a good idea, and as a matter 
> of fact Galene uses token auth for authentication to the TURN server.
> 
> What I'm arguing for is a simple, interoperable user/password 
> mechanism for the simple case, for when the infrastructure required to 
> securely communicate the token to the client is not deemed necessary.  
> My current opinion (likely to change as Sergio and Adam explain stuff 
> to me further) can be summarised as:
> 
>   * HTTP basic: MUST implement in clients, MAY implement in servers;
>   * token: SHOULD implement in clients, SHOULD implement in servers.
>   
> This way, server authors are guaranteed to interoperate with all 
> clients if they choose to implement HTTP Basic, and they can use the 
> more secure token auth if they are willing to put it the work required 
> to build the infrastructure required to communicate tokens to their 
> chosen clients.
> 
> This way, WISH is useful both for Millicast, whose business model 
> relies on helping users deploy their high-quality broadcasting 
> solutions, and for free servers such as Galene, who want to minimise 
> the amount of hand-holding that they need to provide to their 
> non-specialist users, even if that implies not using the most secure 
> authentication techniques available.
> 
> -- Juliusz
> 


I personally think that would actually needlessly complicate things.
Using Bearer tokens in WHIP right now is as easy as adding an HTTP header in the client, and reading it in the server: that's what my prototypes (who know nothing of oauth) do, so very trivial to implement and seems to be working just fine in my interoperability tests with Sergio.

Any other authentication mechanism implemented by services (including Basic Auth) could be reused anyway, as they can be what's used in a custom API to, e.g., generate the unique token you'll then use in the WHIP client (and check in the server).

Lorenzo

--
I'm getting older but, unlike whisky, I'm not getting any better https://protect2.fireeye.com/v1/url?k=53689319-0cf3aa34-5368d382-8692dc8284cb-5e768c3ce9c5456f&q=1&e=28817502-5c33-425b-bdd6-a236a4d69a97&u=https%3A%2F%2Ftwitter.com%2Felminiero

--
Wish mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/wish