Subject: [Wish] Authentication for resource url

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 8 Sep 2021 16:30:58 +0200

Hi all,

Lorenzo asked me a question regarding how the authentication of the
resource url returned on the location header (the one in which the DELETE
and PATCH requests are sent) and I am not sure about the right answer.

I think we have the following options:
 - Use the same mechanism/info as the initial request to the whip url (i.e.
sending the Authentication header with the same bearer token)
 - Returning a randomized opaque unique url
 - Allow using both?

The randomized opaque url is something that the server is always free to
implement, but should we explicitly  state in the draft that the client
must send the same authentication header on those requests?

Best regards
Sergio

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 8 Sep 2021 17:06:25 +0200

On Wed, 8 Sep 2021 16:30:58 +0200
Sergio Garcia Murillo <[email-masked]> wrote:

> resource url returned on the location header (the one in which the
> DELETE and PATCH requests are sent) and I am not sure about the right
> answer.
> 
>  - Use the same mechanism/info as the initial request to the whip url
> (i.e. sending the Authentication header with the same bearer token)
> The randomized opaque url is something that the server is always free
> to implement, but should we explicitly  state in the draft that the
> client must send the same authentication header on those requests?
> 
> Best regards
> Sergio

Hi all,

it makes sense to me that the same token should be used for both
addresses, but I guess in some implementations it may be problematic in
case (as it will often happen) those addresses are actually handled by
different servers. In general, I think the Authorization section of the
document should be made a bit clearer, as it's not explained whether
the same token is required for the PATCH requests to send trickle
candidates too, for instance (the obvious answer for me being "yes",
but I think making it explicit in the draft won't harm).

Lorenzo

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 08 Sep 2021 19:27:11 +0200

>  - Returning a randomized opaque unique url 

I think this is better left unspecified in the normative part of the
document, but should be explained in detail in the Security Considerations
section or in an informative appendix.

-- Juliusz

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 10 Sep 2021 09:24:52 +0200

The second method (returning an unique url) could be detailed on the
security considerations, but sending the same authentication bearer token
in both requests should be in the normative part.

Somehow, I don't like any of both ideas, sending the same token in both
requests doesn't feel appropriate as the idea is that the whip endpoint and
the whip resource could be in different servers, so the token for the
PATH/DELETE request is most probably irrelevant for the media server.

But returning an unique url doesn't seem a very secure idea. Anyway, if
anyone could get access to the resource url. On the other hand, if an
attacker has access to the url in the http response, it would most probably
have access to the data in the request (i.e. the token).

What do you think?
Sergio

El mié, 8 sept 2021 a las 19:27, Juliusz Chroboczek (<[email-masked]>)
escribió:

> (i.e.

---

From: Adam Roach <[email-masked]>
Date: Fri, 10 Sep 2021 22:58:54 -0500

This is OAUTH, right? They might be different servers, but I would 
expect them to be the same audience (as OAUTH uses that term) -- 
implying that the same token would be applicable to both of them (if my 
understanding is correct).

My relatively strong preference is to specify that the same token is 
used for the requests; and, that being the case, it's not clear what 
additional security properties you gain by putting a token in the URL 
path (but I'm not, strictly speaking, opposed to it -- I just don't see 
the value).

/a

On 9/10/2021 2:24 AM, Sergio Garcia Murillo wrote:
> security considerations, but sending the same authentication bearer 
> token in both requests should be in the normative part.
>
> Somehow, I don't like any of both ideas, sending the same token in 
> both requests doesn't feel appropriate as the idea is that the whip 
> endpoint and the whip resource could be in different servers, so the 
> token for the PATH/DELETE request is most probably irrelevant for the 
> media server.
>
> But returning an unique url doesn't seem a very secure idea. Anyway, 
> if anyone could get access to the resource url. On the other hand, if 
> an attacker has access to the url in the http response, it would most 
> probably have access to the data in the request (i.e. the token).
>
> What do you think?
> Sergio
>
> El mié, 8 sept 2021 a las 19:27, Juliusz Chroboczek (<[email-masked] 
> <mailto:[email-masked]>>) escribió:
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 11 Sep 2021 14:56:45 +0200

As said in a different email, we are not mandating the usage of oauth2.

Anyway, in my implementation the token is a unique value that is matched
against database on the whip enpoint. Media servers don't have access to
that database.

It doesn't harm my implementation to receive y
the token on the media server, but not sure if we should mandate it if
there are no plans for using it.

Best regards
Sergio

El sáb., 11 sept. 2021 5:59, Adam Roach <[email-masked]> escribió:

> This is OAUTH, right? They might be different servers, but I would expect
> them to be the same audience (as OAUTH uses that term) -- implying that the
> same token would be applicable to both of them (if my understanding is
> correct).
>
> My relatively strong preference is to specify that the same token is used
> for the requests; and, that being the case, it's not clear what additional
> security properties you gain by putting a token in the URL path (but I'm
> not, strictly speaking, opposed to it -- I just don't see the value).
>
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Sat, 11 Sep 2021 14:03:49 -0500

On 9/11/2021 7:56 AM, Sergio Garcia Murillo wrote:
> Anyway, in my implementation the token is a unique value that is 
> matched against database on the whip enpoint. Media servers don't have 
> access to that database.
>

Our infrastructure uses a bearer token (it's a cryptographically-signed 
assertion, so no database required), and it would be kind of a pain to 
require a securely random URL in addition to that. So I'm happy with the 
original formulation from your previous message, wherein the client must 
send the auth token, but the media server can use that or another 
mechanism (such as a sufficiently random URL) to validate that the 
operation is authorized.

/a

---

From: Matt Ward <[email-masked]>
Date: Sun, 12 Sep 2021 12:14:28 -0700

I put this in
https://github.com/wish-wg/webrtc-http-ingest-protocol/issues/16 but here's
a quick cross post of my thoughts.

Today, we do rtmp://live.mux.com/app/{STREAM_KEY} and are imagining support
for WHIP via something akin to https://whip.mux.com/{STREAM_KEY}. In such a
case, this simple URL by itself contains what we believe to be sufficiently
"secret" information to secure ingestion (as we have done this same thing
for years in the RTMP world).

I've proposed an edit in
https://github.com/wish-wg/webrtc-http-ingest-protocol/pull/17 clarifying
that "any HTTP compliant authentication and authorization MAY be
implemented" and that RFC6750 is an example.

On Sat, Sep 11, 2021 at 12:04 PM Adam Roach <[email-masked]> wrote:

> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Adam Roach <[email-masked]>
Date: Sun, 12 Sep 2021 16:49:59 -0500

On 9/12/2021 2:14 PM, Matt Ward wrote:
> I've proposed an edit in 
> https://github.com/wish-wg/webrtc-http-ingest-protocol/pull/17 
> clarifying that "any HTTP compliant authentication and authorization 
> MAY be implemented" and that RFC6750 is an example.

I understand the motivation, but this doesn't get us to 
interoperability. We need a baseline, mandatory-to-implement 
authentication method for both client and server; otherwise, we'll end 
up in a situation where your client implements mechanism A, my network 
implements mechanism B, and your users can't use my network.

/a

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 13 Sep 2021 18:14:28 +0200

> authentication method for both client and server; otherwise, we'll end up
> in a situation where your client implements mechanism A, my network

Yes, and that is why I suggested HTTP Basic instead of bearer token.

Most servers today implement authentication using a username/password
pair.  While this is certainly not the most secure solution, it is well
understood by users, and is therefore likely to remain the main mode of
authentication for the foreseeable future.

With HTTP Basic, it is perfectly clear how to map a username/password pair
to the protocol.  With bearer token, the client and the server need to
both agree on how to map the username/password pair to a token, and
I expect different implementations to use different mappings, with all the
fun that this entails.

So I suggest that for clients:

  - support for unauthenticated WISH over HTTPS is MUST;
  - support for HTTP Basic over HTTPS is MUST;
  - other authentication methods is MAY.

If that is not what Sergio has in mind, then the draft needs to mandate an
unambiguous and deterministic way of mapping a username/password pair to
an authentication method.

-- Juliusz

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 13 Sep 2021 18:30:34 +0200

I disagree with the approach.

IMHO, using username/password authentication in http rest apis is insecure
as it forces the user to store it's password into several "low security"
applications and most service providers have deprecated it in favor of a
token based authentication.

My proposal would be that it is a MUST for clients to support
authentication via the bearer token and it would be optional for the server
to implement it or not. In case the user does not provision the token on
the whip client, an unauthenticated request would be sent to the server.

Best regards
Sergio

---

From: Matt Ward <[email-masked]>
Date: Mon, 13 Sep 2021 10:29:06 -0700

In the current abstract for WHIP, the spec comes out stating "Currently
there is no standard protocol (like SIP or RTSP) designed for ingesting
media in a streaming service, and content providers still rely heavily on
protocols like RTMP for it."

Why do content providers rely on RTMP and possibly more interestingly, why
do publishers/broadcasters/end-users love RTMP?

It is dead simple.

If our goal is to replace RTMP, I think we need to allow clients to be as
dead simple as RTMP is today. In order to do this, we must allow clients to
ship with support for only path based authentication as in RTMP. This will
require a minimal amount of UI/UX changes and speed time to support in many
broadcasting software/appliances.

As for MAY support beyond that, I'd look at how custom RTMP is configured
in OBS. To that end, it only supports authentication via basic auth. I
imagine adding support for bearer authentication that's only supported for
WHIP in OBS adds complexity to that client. I imagine this additional
burden would not be uncommon across the space of existing broadcasting
software/appliances. As for one more example, I have seen approximately 0
ffmpeg example commands outputting with bearer authentication.

On Mon, Sep 13, 2021 at 9:30 AM Sergio Garcia Murillo <
[email-masked]> wrote:

>> up

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 13 Sep 2021 19:55:23 +0200

Not sure how an RTMP implementation may affect how OBS or ffmpeg implements
WHIP, should be as simple as this:

El lun, 13 sept 2021 a las 19:29, Matt Ward (<[email-masked]>) escribió:

>> IMHO, using username/password authentication in http rest apis is
>> insecure as it forces the user to store it's password into several "low
>> security" applications and most service providers have deprecated it in
>> favor of a token based authentication.
>>

---

From: Matt Ward <[email-masked]>
Date: Mon, 13 Sep 2021 10:56:17 -0700

AFAIK today, there's no "Auth token" input for any of the other services?
Have you found an ffmpeg output that supports bearer
authentication? Usually, more UI/params/config => more state => more
complex clients => longer time to integrate.

I want every single box that supports RTMP today to add WHIP tomorrow with
minimal friction!  :)

On Mon, Sep 13, 2021 at 10:55 AM Sergio Garcia Murillo <
[email-masked]> wrote:

> Not sure how an RTMP implementation may affect how OBS or ffmpeg
> implements WHIP, should be as simple as this:
>
>
>> Why do content providers rely on RTMP and possibly more interestingly,
>> why do publishers/broadcasters/end-users love RTMP?
>>
>> It is dead simple.
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 13 Sep 2021 20:09:12 +0200

FWIW, I did implement the initial whip draft in OBS and doing the UX for
configuring the oauth token is trivial. The problem with ffmpeg is not
going to be the bearer token authentication neither.. ;)

El lun, 13 sept 2021 a las 19:56, Matt Ward (<[email-masked]>) escribió:

>>> If our goal is to replace RTMP, I think we need to allow clients to be
>>> as dead simple as RTMP is today. In order to do this, we must allow clients
>>> to ship with support for only path based authentication as in RTMP. This
>>> will require a minimal amount of UI/UX changes and speed time to support in
>>> many broadcasting software/appliances.
>>>
>>> As for MAY support beyond that, I'd look at how custom RTMP is
>>> configured in OBS. To that end, it only supports authentication via basic
>>> auth. I imagine adding support for bearer authentication that's only
>>> supported for WHIP in OBS adds complexity to that client. I imagine this
>>> additional burden would not be uncommon across the space of existing
>>> broadcasting software/appliances. As for one more example, I have seen
>>> approximately 0 ffmpeg example commands outputting with bearer
>>> authentication.
>>>
>>>
>>>

---

From: Matt Ward <[email-masked]>
Date: Mon, 13 Sep 2021 11:21:56 -0700

It may be trivial for you to wrap your head around as the author of the
spec and a strong engineer. However, I still feel quite strongly that
converting a community of broadcasters (with a wide range of technical
understanding) from RTMP => WHIP is easier if the protocol drops into
existing UIs with near 0 changes required.

Imagine working at Blackmagic or Teradek and seeing a requirement to add a
bunch of UI in addition to a whole new underlying protocol. I suspect
requiring even basic auth there will slow adoption.

On Mon, Sep 13, 2021 at 11:09 AM Sergio Garcia Murillo <
[email-masked]> wrote:

>> I want every single box that supports RTMP today to add WHIP tomorrow
>> with minimal friction!  :)
>>

---

From: Cameron Elliott <[email-masked]>
Date: Mon, 13 Sep 2021 15:30:50 -0700

I think I appreciate (I hope anyway) what Matt and Juliusz are getting at.

Well, from my perspective, it seems to be the idea that authentication
should be easily understandable and grasped by
developers who are NOT OAuth familiar, and NOT RFC 6750 familiar, and even
non-developer end-users also.
This sounds like a great goal.

>From my perspective the RFC 6750 makes things unnecessarily complicated.
Well maybe it's necessary
in the context of OAuth, but for non-OAuth usage, it seems complicated.

I totally understand, it might not be clear how to do super-simple end-user
auth without OAuth using the short description
in the draft.

But the nice thing about a bearer token approach, is it can support all the
different models that have been discussed.
- OBS stream-key
- username/password (well password-only)
- The different OAuth models

Again, I think the criticisms from Matt & Julius make sense, it's not clear
how to use RFC 6750 in even
the most basic way, unless you have a certain amount of experience around
using bearer tokens for auth.
(I will note, bearer tokens are the most common way to authenticate APIs
these days, not username/password)

Maybe what is needed are two simple examples in the spec that show how
bearer tokens would be used:
1. concrete example comparing how it can be used as an alternative to
username/password. (http basic auth alternative)
2. concrete example comparing how it can be used as an alternative to
passing stream-keys in the URL.

Might really go a long  way to making it clear how to do auth in non-oauth
scenarios where 'http basic auth' or
'url based stream keys' have been used previously.

Cameron

On Mon, Sep 13, 2021 at 11:22 AM Matt Ward <[email-masked]> wrote:

>>> AFAIK today, there's no "Auth token" input for any of the other
>>> services? Have you found an ffmpeg output that supports bearer
>>>>> In the current abstract for WHIP, the spec comes out stating
>>>>> "Currently there is no standard protocol (like SIP or RTSP) designed for
>>>>> ingesting media in a streaming service, and content providers still rely
>>>>> heavily on protocols like RTMP for it."
>>>>>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 14 Sep 2021 02:17:54 +0200

> username/password. (http basic auth alternative)

It's not about giving an example, it's about giving a normative way of
using username/password with WHIP.

For better or worse, Galene uses username/password for authentication, as
does every other videoconference server known to me.  If a user know the
group URL and their username/password, they can use Galene.  I want them
to be able to access Galene over WHIP, and while I'm happy to write extra
code (which needs only be done once), I don't want to do any extra
per-user setup (which needs to be done once per user).

If there is a normative way of using bearer tokens with password auth,
then please give us the RFC number so we can implement it.  If there is
none, then I suggest we make HTTP Basic mandatory to implement in clients.

-- Juliusz

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 14 Sep 2021 09:51:15 +0200

> none, then I suggest we make HTTP Basic mandatory to implement in clients.
Using an username and password for authentication is very limited and for
sure does not cover all the use cases for whip. Maybe on your
implementation that username and password was just used for the
conferencing solution, so a simple solution works for you.

However there are a lot of cases when a username and password is clearly
inefficient and not fit for the job:

- Using third party authentication: many web pages allows to log in using
external account (google, facebook, github), in this case you may not even
have an username and password for that account, or are you going to ask
someone to introduce their google mail and password in you encoder to be
able to stream it?.
- The account is used for much more than just the streaming service and
they would allow you to log into your service and perform a lot of
operations on your behalf. Would you be comfortable giving your credentials
to an external only service that could be hacked and your password exposed
in the wild?
- Most of the time the streaming service is not used by a single person,
each person having a unique login but sharing the account, which
credentials would you use in that case?

That's why most rest apis are using token authentication instead of just
using the username/password for the service. Even more, for example
github does not even allow you to use your username and password anymore on
git clients with ssh but you have to create an app token as secret in order
to prevent your account from being compromised if that info is leaked.

The actual value and format of the token is completely service specific and
we don't need to specify it. As a service provider you have a wide range of
options:

   - Generate a unique random token, associate it to a stream/account on
   your service and persist it on db or similar, then use a generic url
   /whip/endpoint for all the requests and retrieve the stream info associated
   with the bearer token from the db.
   - Generate a signed jwt containing the stream/account information which
   does not require to be persisted on the db,  then use a generic url
   /whip/endpoint for all the requests and extract the stream info from the
   jwt once the signature is validated
   - A variation of this would be to put the token on the url itself
   /whip/endpoint?token=${token} and not use a bearer token at all
   - Generate a custom token (like base64(${username}:${password})),  then
   use a generic url /whip/endpoint for all the requests and extract the
   stream info from the token. [insecure]
   - Put the username in the url /whip/endpoint/${username} and use the
   password as token [insecure]
   - use oath2, 2fa,...

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 14 Sep 2021 09:54:53 +0200

I agree that the wording in the current draft and the reference to the  RFC
6750 is not clear at all, I will try to improve on the next versions of the
draft.

I have tried to explain different usages of the auth token in a response to
a former email by Juliusz explaining how the service could make use of it
in different ways.

However, not sure how much of that info should be in the draft as the
examples are not normative but implementation specific.

Best regards
Sergio

El mar, 14 sept 2021 a las 0:31, Cameron Elliott (<
[email-masked]>) escribió:

> I totally understand, it might not be clear how to do super-simple
> end-user auth without OAuth using the short description
> in the draft.
>
> But the nice thing about a bearer token approach, is it can support all
> the different models that have been discussed.
> - OBS stream-key
> Again, I think the criticisms from Matt & Julius make sense, it's not
> clear how to use RFC 6750 in even
>> Imagine working at Blackmagic or Teradek and seeing a requirement to add
>> a bunch of UI in addition to a whole new underlying protocol. I suspect
>>>>>> Why do content providers rely on RTMP and possibly more
>>>>>> interestingly, why do publishers/broadcasters/end-users love RTMP?
>>>>>>
>>>>>> It is dead simple.
>>>>>>
>>>>>> If our goal is to replace RTMP, I think we need to allow clients to
>>>>>> be as dead simple as RTMP is today. In order to do this, we must allow
>>>>>> clients to ship with support for only path based authentication as in RTMP.
>>>>>> This will require a minimal amount of UI/UX changes and speed time to
>>>>>> support in many broadcasting software/appliances.
>>>>>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 14 Sep 2021 09:58:58 +0200

I think in terms of UI it is very similar to what people are used to, for
example this OBS UI to connect to facebook would be exactly the same than
the one required for whip:

Where server is the whip endpoint url and the stream key the bearer token
sent on the authentication header. Even the "get stream key" button would
work the same way.

Best regards
Sergio

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 14 Sep 2021 13:18:19 +0200

> Using an username and password for authentication is very limited and for sure
> does not cover all the use cases for whip.

I understand that, and I am all in favour of people implementing better
authentication mechanisms.

What I am requesting here is an MTI authentication mechanism that
guarantees interoperability between independent implementations of WHIP.
In other words, I am asking for guidance about what I need to implement so
I can ensure that I interoperate with all WHIP clients, including those
that haven't been written yet.

> * Generate a unique random token, associate it to a stream/account on your
>   service and persist it on db or similar

What procedure do you suggest for securely communicating the token to each
user?  The obvious solution would be to make it available over HTTPS
protected by HTTP Basic, but then, we might as well cut out the middleman
and use HTTP Basic for WHIP.

> * Generate a signed jwt containing the stream/account information which does
>   not require to be persisted on the db,  then use a generic url
>   /whip/endpoint for all the requests and extract the stream info from the jwt
>   once the signature is validated

I assume this implies that the client is generating the token in
a compatible manner.  If we want to ensure interoperability, we need to
normatively reference a document that describes the procedure.

> * Generate a custom token (like base64(${username}:${password})),  then use a
>   generic url /whip/endpoint for all the requests and extract the stream info
>   from the token. [insecure]

I wouldn't be opposed to implementing that, but, again, this implies that
the client is generating the token in a compatible manner.  So we need
a normative reference so we can ensure interoperability.

-- Juliusz

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 14 Sep 2021 14:44:58 +0200

I think this is root cause of the confusion, the client does not generate
or retrieve the token anyhow.

The server/service makes it available to the user somehow (out of the scope
of this document) and the end user configures it on the client (alongside
with the whip url):

Best regards
Sergio

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 14 Sep 2021 17:22:36 +0200

> I think this is root cause of the confusion, the client does not generate or
> retrieve the token anyhow.

I am increasingly confused.

> The server/service makes it available to the user somehow (out of the scope of
> this document) and the end user configures it on the client

So what you are saying is that WHIP does not depend on OAuth2, but it does
depend on some unspecified token provisioning protocol?

Please explain.

-- Juliusz

---

From: Adam Roach <[email-masked]>
Date: Tue, 14 Sep 2021 12:32:43 -0500

> depend on some unspecified token provisioning protocol?

Not really. At least, not in the engineering sense of the word "protocol."

What you need to do is get tokens to the users (users! not clients!) 
somehow so that they can set up their client. Exactly how you do that is 
entirely up to you. You also need to get a WHIP URL to users somehow so 
that they can set up their client. How you do that is also entirely up 
to you in exactly the same way.

Once users get those two bits of information from you (URL and Token), 
they put them into a WHIP client, and are ready to broadcast.

The client has to understand enough about the URL to use it in an HTTP 
stack. The client has to understand nothing about the token.

How you generate the token is 100% up to you, as long as your service 
can look at it and (1) tell which account it corresponds to, and (2) 
validate that it is authentic. There are many ways to accomplish this, 
and which one you choose is entirely up to you. Sergio described many 
viable approaches in his earlier message.

[Technically, it is possible for you to encode one or both of those 
things into the URL itself and then leave them out of the token. I would 
recommend against that for reasons that I can go into in a different 
message; but I don't want to make this email too wide ranging.]

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." And then everything just works. 
The client doesn't know whether this long string is some kind of crypto 
token, a random string stored in a database somewhere, or something 
else. As a human, I can't tell either. The only thing that knows how to 
unpack that string into an account identifier and validate that it is 
authentic is Twitch itself.

You can do that, if you like. Or you can hand tokens out on slips of 
paper, if your users are patient. You can send them to users via Signal. 
Really, how you get tokens to users is entirely up to you. And that's 
the important point.

If there are some entirely uncircumventable, non-negotiable constraints 
that entirely prevent you from doing something like what I describe 
above, then you can technically meet the two requirements I mention by 
telling users something like "In the field that asks for an 
authentication token, enter your username, a colon character, and then 
your password." The client doesn't know or care that this is the format 
you're using; only your servers need to know that. And it has the same 
security properties as HTTP Basic Auth, so you're not losing anything 
over what you want to do. (There are reasons I wouldn't use basic auth 
in 2021, but how you secure your system is entirely up to you.)

/a

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 15 Sep 2021 11:25:37 +0200

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

So that's what's considered user-friendly nowadays.  I'm sure my users
will enjoy doing that at the beginning of every lecture.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 15 Sep 2021 11:49:19 +0200

>> Stream Key." You paste this into your broadcast client in a field usually

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 15 Sep 2021 12:18:51 +0200

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Sep 2021 10:42:11 +0000

Hi,

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

Regards,

Christer

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

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

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

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 15 Sep 2021 12:56:37 -0500

> will enjoy doing that at the beginning of every lecture.

I know my message was long, and I apologize for its length, but did you 
make it to the last paragraph? It was aimed at your use case.

/a

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 15 Sep 2021 20:29:47 +0200

> make it to the last paragraph? It was aimed at your use case.

Yes, I did.  You're suggesting a deterministic procedure to map
a username/password to a bearer token, and arguing that it doesn't need to
be normatively definded since it can be communicated out-of-band to the
users.

I'm not sure what I can reply to that.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 15 Sep 2021 20:36:38 +0200

> If the only thing you mandate to support is HTTP basic, would WHIP pass

What issue do you envision?  I could be wrong, but I believe that HTTP Basic
over HTTPS is reasonably secure, and I don't think it violates any IETF
policy.  (Granted, if we expect WHIP to run in cleartext over the public
Internet, then HTTP Basic is too weak.  But I don't think that anyone is
expecting to run WHIP over cleartext except in controlled environments.)

-- Juliusz

---

From: Adam Roach <[email-masked]>
Date: Wed, 15 Sep 2021 14:05:45 -0500

> be normatively definded since it can be communicated out-of-band to the

I'm saying that, /for your server/, that's a choice you can make, and it 
works for your use case. There's going to need to be some kind of 
out-of-band communication to get them the WISH URL anyway, so adding 
that information on doesn't make anything more complicated.

To be clear, I wouldn't expect any other servers to use that scheme.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 15 Sep 2021 14:11:26 -0500

On 9/15/21 13:36, Juliusz Chroboczek wrote:
> if we expect WHIP to run in cleartext

We can't. Our charter doesn't let us define WHIP over HTTP. We're only 
allowed to define WHIP over HTTPS.

/a

---

From: Matt Ward <[email-masked]>
Date: Thu, 16 Sep 2021 10:43:04 -0700

I would still reiterate that I strongly recommend that the spec does not
prohibit the lack of an Authentication header and therefore in some way
permits building an experience really close to that of RTMP such that we do
not have to retrain broadcasters. I think keeping things close to RTMP will
help this spec see better adoption in the ecosystem. I really do want this
spec to succeed and I do believe that keeping the requirements as minimal
as possible will help speed up adoption.

The question here I think should be, is WHIP as a spec actually incomplete
and not independently useful without a specification of authentication? Can
(and should) that be covered in optional extensions of the base spec
that makes no mention of authentication?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 16 Sep 2021 19:48:09 +0200

I think that the spec must mandate authentication to be supported on the
client side and that its usage is optional. Meaning that all clients must
implement it, but allow the token to not be set (and therefore the header
not be sent).

Best regards
Sergio

---

From: Matt Ward <[email-masked]>
Date: Thu, 16 Sep 2021 10:49:25 -0700

Why must it be mandated?

On Thu, Sep 16, 2021 at 10:48 AM Sergio Garcia Murillo <
[email-masked]> wrote:

>> The question here I think should be, is WHIP as a spec actually
>> incomplete and not independently useful without a specification of
>> authentication? Can (and should) that be covered in optional extensions of
>> the base spec that makes no mention of authentication?
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 16 Sep 2021 20:10:57 +0200

Because if not it won't be implemented by clients, and we won't be able to
use it in our servers even if we want it

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 16 Sep 2021 20:19:56 +0200

On Thu, 16 Sep 2021 20:10:57 +0200
Sergio Garcia Murillo <[email-masked]> wrote:

> Because if not it won't be implemented by clients, and we won't be
> able to use it in our servers even if we want it
> 

+1

Lorenzo

> >> I think that the spec must mandate authentication to be supported
> >> on the client side and that its usage is optional. Meaning that
> >> all clients must implement it, but allow the token to not be set
> >> (and therefore the header not be sent).
> >>
> >> Best regards
> >> Sergio
> >>
> >>> I would still reiterate that I strongly recommend that the spec
> >>> does not prohibit the lack of an Authentication header and
> >>> therefore in some way permits building an experience really close
> >>> to that of RTMP such that we do not have to retrain broadcasters.
> >>> I think keeping things close to RTMP will help this spec see
> >>> better adoption in the ecosystem. I really do want this spec to
> >>> succeed and I do believe that keeping the requirements as minimal
> >>> authentication? Can (and should) that be covered in optional
> >>> extensions of the base spec that makes no mention of
> >>> authentication?
> >>>
> >>>> We can't. Our charter doesn't let us define WHIP over HTTP.
> >>>> We're only allowed to define WHIP over HTTPS.
> >>>>
> >>>> /a
> >>>>
> >>>> --
> >>>> Wish mailing list
> >>>> [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 16 Sep 2021 20:44:26 +0200

> Why must it be mandated?

It's fairly standard at IETF, as far as I'm aware.

The IETF insists that every protocol have a "mandatory to implement" (MTI)
security mechanism that ensures interoperability.  MTI does not means that
the mechanism needs to be enabled by default, just that it can be easily
enabled by the user if required.  (I expect most clients to be unauthentified
by default.)

The debate we're having is not about what mechanisms we'll be allowed to
implement -- it's highly unlikely that an angry Sergio will suddenly
appear in my office and try to prevent me from implementing HTTP Basic.
The debate is about what mechanism should be MTI according to the spec,
since that is the mechanism that's most likely to be implemented in
a uniform manner by third-party clients.

-- Juliusz