Re: [Wish] Authentication for resource url

Lorenzo Miniero <lorenzo@meetecho.com> Wed, 08 September 2021 15:06 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2588E3A2B4D for <wish@ietfa.amsl.com>; Wed, 8 Sep 2021 08:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.211
X-Spam-Level:
X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_DYNAMIC_DHCP=0.206, RCVD_IN_MSPIKE_H2=-0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyjLdqA4jnpy for <wish@ietfa.amsl.com>; Wed, 8 Sep 2021 08:06:30 -0700 (PDT)
Received: from smtpcmd01-sp1.aruba.it (smtpcmd01-sp1.aruba.it [62.149.158.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7C3A0B15 for <wish@ietf.org>; Wed, 8 Sep 2021 08:06:29 -0700 (PDT)
Received: from lminiero ([2.232.93.8]) by Aruba Outgoing Smtp with ESMTPSA id Nz9dmL76IJzjeNz9dmWeAI; Wed, 08 Sep 2021 17:06:28 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1631113588; bh=i6p6ZnYxRLYkQWWc0KGAbdMxYAdv7T0ARltEqNNg0FI=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=cBMJ1LSM0t8ftueicWtnFHEEWepn6ebuzP2aBVGsX+oqvAv4VKhK8jeS2lwoUfsGe OLAYnsoet3RfLocNgjUjaKy/ro4fatIDU/FtcFd0Y0avSrb6JyhxQQPmY/PtbEMFzn 0uCIyFBj6xCg9iqzoQrjp9rcuTAjX4afFTp8njJL+zBOzKuHvmhziOkEgLkNYslHR7 Ro0JGgiHTTQof7VYRLEYVdZiLNQ0iSExiUFZeZP9axaQLvqnzGoyyldXhyb578Z5q0 aIGQXGa8YYQ+EgruLVyi/bQY8JQN8vCl4jBRUxaB2pQeZKrthZnVpAu4pJkuJ7sFJk 5SpLaMljqE3TA==
Date: Wed, 8 Sep 2021 17:06:25 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: WISH List <wish@ietf.org>
Message-ID: <20210908170625.697f8b39@lminiero>
In-Reply-To: <CA+ag07bjtS1Ucw1BZ5qQ_jJFfXbfQ3-hzDgxfkV1APhV1JZMnQ@mail.gmail.com>
References: <CA+ag07bjtS1Ucw1BZ5qQ_jJFfXbfQ3-hzDgxfkV1APhV1JZMnQ@mail.gmail.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfB+qoiusUIlt5miR7DuGeglUA+vUqzcehuYz1j64gJySX+aD6Zkv82g0QfnZA8TT/j5goDUf4MbBERTEoTAHhocoCKzJ1U60g9FTrqWzWyc7mN3dMAXT yOGP8LIDpZ4DggRBauJdpi9VgV7qziKYJyQqBYbQGW2p4I6TtmIhUmzppg1c0gSlkOT6GugTKkNaag==
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/c6fupNf2bqmHgry8syeghR47How>
Subject: Re: [Wish] Authentication for resource url
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2021 15:06:35 -0000

On Wed, 8 Sep 2021 16:30:58 +0200
Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

> 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


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