Icecast - Jun 2020 - Empty username and password for stream_auth

Hi,

we are using Icecast with url authentication for some days now. This generally
works quite well. But our web service that provides the authentication check
sometimes gets requests with the following parameters:

{
"action":"stream_auth",
"mount":"/stream",
"ip":"xxxxx",
"server":"xxxx.yyyy.de",
"port":"12345",
"user":"",
"pass":"",
"admin":"1"
}

The passed username and password is empty. Why does this happen and what should
our authentication provider response to such a request?
Currently we response with HTTP status code 403 and the header
"Icecast-Auth-Message: No username provided".

Icecast logs the following at the time of the request:
> [2020-06-11 10:08:57] INFO auth/auth_stream_authenticate request source
auth for "/stream"
> [2020-06-11 10:08:57] INFO auth/queue_auth_client auth on /stream has 1
pending
> [2020-06-11 10:08:57] WARN auth/stream_auth_callback Failed auth for source
"/stream"
I hope you can help me.

Best regards

Mit freundlichen Grüßen aus Paderborn

Christian Stoller
Web-Entwicklung

LEONEX Internet GmbH
Technologiepark 6
33100 Paderborn
Tel: +49 (5251) 4142-526
Fax: +49 (5251) 4142-501


HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter

________________________________
LEONEX ist Google Premier Partner.
Mit der staatlichen Förderung Go-Digital in die Digitalisierung. Wir sind Ihr
Ansprechpartner für
erfolgreiche Webauftritte, E-Commerce, individuelle Softwarelösungen,
Online-Marketing und Hosting.
________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20200616/16025270/attachment.html>

Good morning,

On Tue, 2020-06-16 at 13:25 +0000, Christian Stoller
wrote:
> Hi,
> 
> we are using Icecast with url authentication for some days now. This
> generally works quite well. But our web service that provides the
> authentication check sometimes gets requests with the following
> parameters:
> 
> {
> "action":"stream_auth",
> "mount":"/stream",
> "ip":"xxxxx",
> "server":"xxxx.yyyy.de",
> "port":"12345",
> "user":"",
> "pass":"",
> "admin":"1"
> }
> 
> The passed username and password is empty. Why does this happen and
> what should our authentication provider response to such a request?
This is perfectly correct and totally expected:
HTTP does the auth in two steps: First a request is sent with no
credentials. In this step the request will pass (no credentials needed)
or the server will reply parameters on how to provide them. This is
important as otherwise the client would send credentials blindly,
allowing a wide range of attacks (both passive and active).

If asked by the server, the client will then retry again with
credentials. Which will then let Icecast ask the backend again.


Why does Icecast forward both requests? Very simple: Not all auth setups
require username:password. E.g. some are only for logging and
accounting. Some auth using the IP address, which is already known in
the first request.

(That said, Iecast 2.5.x (current development versions) can be
configured to reject those request without asking the backend.)

> Currently we response with HTTP status code 403 and the header
> "Icecast-Auth-Message: No username provided".
If you require username:password for auth, then reject those requests to
let Icecast tell the client.

Generally you should reply with a positive status code to Icecasts
requests. The status code you send is about the request from Icecast to
your backend server, not for the request from the client to Icecast.

> Icecast logs the following at the time of the request:
> > [2020-06-11 10:08:57] INFO auth/auth_stream_authenticate request
> source auth for "/stream"
> > [2020-06-11 10:08:57] INFO auth/queue_auth_client auth on /stream
> has 1 pending
> > [2020-06-11 10:08:57] WARN auth/stream_auth_callback Failed auth for
> source "/stream"
> 
> I hope you can help me.
Hope that helped. :)

> Best regards
> 
> Mit freundlichen Grüßen aus Paderborn

Mit freundlichen Grüßen aus Südhessen,

-- 
Philipp Schafft (CEO/Geschäftsführer) 
Telephon: +49.3535 490 17 92

Löwenfelsen UG (haftungsbeschränkt)     Registration number:
Bickinger Straße 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20200617/a9d68155/attachment.sig>

Hi Philipp,

Thanks for your reply. It really helped.

Did I understand you correctly that we should respond to those requests sent by
Icecast without username and password with HTTP status code 200 and the header
"Icecast-Auth-Message: No username provided"?

Best regards,
Christian
> Good morning,
>
> On Tue, 2020-06-16 at 13:25 +0000, Christian Stoller wrote:
>> Hi,
>>
>> we are using Icecast with url authentication for some days now. This
>> generally works quite well. But our web service that provides the
>> authentication check sometimes gets requests with the following
>> parameters:
>>
>> {
>> "action":"stream_auth",
>> "mount":"/stream",
>> "ip":"xxxxx",
>> "server":"xxxx.yyyy.de",
>> "port":"12345",
>> "user":"",
>> "pass":"",
>> "admin":"1"
>> }
>>
>> The passed username and password is empty. Why does this happen and
>> what should our authentication provider response to such a request?
>
> This is perfectly correct and totally expected:
> HTTP does the auth in two steps: First a request is sent with no
> credentials. In this step the request will pass (no credentials needed)
> or the server will reply parameters on how to provide them. This is
> important as otherwise the client would send credentials blindly,
> allowing a wide range of attacks (both passive and active).
>
> If asked by the server, the client will then retry again with
> credentials. Which will then let Icecast ask the backend again.
>
>
> Why does Icecast forward both requests? Very simple: Not all auth setups
> require username:password. E.g. some are only for logging and
> accounting. Some auth using the IP address, which is already known in
> the first request.
>
> (That said, Iecast 2.5.x (current development versions) can be
> configured to reject those request without asking the backend.)
>
>
>> Currently we response with HTTP status code 403 and the header
>> "Icecast-Auth-Message: No username provided".
>
> If you require username:password for auth, then reject those requests to
> let Icecast tell the client.
>
> Generally you should reply with a positive status code to Icecasts
> requests. The status code you send is about the request from Icecast to
> your backend server, not for the request from the client to Icecast.
>
>
>> Icecast logs the following at the time of the request:
>> > [2020-06-11 10:08:57] INFO auth/auth_stream_authenticate request
>> source auth for "/stream"
>> > [2020-06-11 10:08:57] INFO auth/queue_auth_client auth on /stream
>> has 1 pending
>> > [2020-06-11 10:08:57] WARN auth/stream_auth_callback Failed auth
for
>> source "/stream"
>>
>> I hope you can help me.
>
> Hope that helped. :)
>
>
>> Best regards
>>
>> Mit freundlichen Grüßen aus Paderborn
>
>
> Mit freundlichen Grüßen aus Südhessen,
>
> --
> Philipp Schafft (CEO/Geschäftsführer)
> Telephon: +49.3535 490 17 92
>
> Löwenfelsen UG (haftungsbeschränkt) Registration number:
> Bickinger Straße 21 HRB 12308 CB
> 04916 Herzberg (Elster) VATIN/USt-ID:
> Germany DE305133015
Mit freundlichen Grüßen aus Paderborn

Christian Stoller
Web-Entwicklung

LEONEX Internet GmbH
Technologiepark 6
33100 Paderborn
Tel: +49 (5251) 4142-526
Fax: +49 (5251) 4142-501


HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter

________________________________
LEONEX ist Google Premier Partner.
Mit der staatlichen Förderung Go-Digital in die Digitalisierung. Wir sind Ihr
Ansprechpartner für
erfolgreiche Webauftritte, E-Commerce, individuelle Softwarelösungen,
Online-Marketing und Hosting.
________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20200617/ce6ed154/attachment.html>

On Wed, Jun 17, 2020 at 07:55:05AM +0000, Philipp Schafft
wrote:
> Why does Icecast forward both requests? Very simple: Not all auth setups
> require username:password. E.g. some are only for logging and
> accounting. Some auth using the IP address, which is already known in
> the first request.
Indeed.  One of my streams has requested geoblocking, which uses
exactly the mechanism you describe.

-- 
Paul Martin <pm at nowster.me.uk>