IETF Logo Mail Archive

Re: [Wish] Authentication for resource url

Adam Roach <adam@nostrum.com> Sat, 11 September 2021 19:04 UTC

Return-Path: <adam@nostrum.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 223D73A2234 for <wish@ietfa.amsl.com>; Sat, 11 Sep 2021 12:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level:
X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 dI1FrtnFj6Nz for <wish@ietfa.amsl.com>; Sat, 11 Sep 2021 12:04:04 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBD73A18E4 for <wish@ietf.org>; Sat, 11 Sep 2021 12:04:02 -0700 (PDT)
Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 18BJ3sKm080447 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 11 Sep 2021 14:03:55 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1631387035; bh=6xHrS4eFyyTQionLeFz5BkYk7qVwAbJPS9EZUIINZ4w=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=tMSeAY8Pt/p3J822P0ftS393Br7yS/rKqTLaFa9bPAZPfWx5eiAMTD3cIrYFsqglz oJxUFHRK0ESoE1SkYaRrsP9vizhVqxHUWWE+k4QPqaRQAkikn4veiB++G3tAVrPPMe sNDN6wQVtDZMFEjqoXkmvdVn2+FpZ9ixTajAQDxs=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48]
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, WISH List <wish@ietf.org>
References: <CA+ag07bjtS1Ucw1BZ5qQ_jJFfXbfQ3-hzDgxfkV1APhV1JZMnQ@mail.gmail.com> <87o893vuz4.wl-jch@irif.fr> <CA+ag07Y41bg_K-60=d5yyODj+bN442enQn-Grb-NkX7zQ8vVBQ@mail.gmail.com> <1e55c847-6a6c-5fca-d7c0-cd3a822855a7@nostrum.com> <CA+ag07YZdQooVBLtn=R=Lj0XpojCmVzd51P6=ExFUqwhvqYNdA@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <28d39165-3d08-257e-4736-1c8449e99034@nostrum.com>
Date: Sat, 11 Sep 2021 14:03:49 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <CA+ag07YZdQooVBLtn=R=Lj0XpojCmVzd51P6=ExFUqwhvqYNdA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/QHM4fjpAIS7izKobc0yCIGXkRNA>
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: Sat, 11 Sep 2021 19:04:09 -0000

On 9/11/2021 7:56 AM, Sergio Garcia Murillo wrote:
> 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.


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

v2.8.7 | Report a Bug | By Email