Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem

Nico Williams <nico@cryptonector.com> Tue, 31 March 2020 05:54 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A2F3A1BBB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 30 Mar 2020 22:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.851
X-Spam-Level:
X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 EoLrU1A2wAJE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 30 Mar 2020 22:54:35 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40F43A1BBA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 30 Mar 2020 22:54:34 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jJ9o0-0007Vg-2M for ietf-http-wg-dist@listhub.w3.org; Tue, 31 Mar 2020 05:51:21 +0000
Resent-Date: Tue, 31 Mar 2020 05:51:20 +0000
Resent-Message-Id: <E1jJ9o0-0007Vg-2M@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <nico@cryptonector.com>) id 1jJ9nv-0007Uv-MR for ietf-http-wg@listhub.w3.org; Tue, 31 Mar 2020 05:51:15 +0000
Received: from buffalo.birch.relay.mailchannels.net ([23.83.209.24]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <nico@cryptonector.com>) id 1jJ9ns-0004iC-MT for ietf-http-wg@w3.org; Tue, 31 Mar 2020 05:51:15 +0000
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 389001006B4; Tue, 31 Mar 2020 05:51:00 +0000 (UTC)
Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-12-20.trex.outbound.svc.cluster.local [100.96.12.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AE05D100855; Tue, 31 Mar 2020 05:50:59 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 31 Mar 2020 05:51:00 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Invention-Thread: 45385e151954189e_1585633859981_3342648246
X-MC-Loop-Signature: 1585633859980:2500628170
X-MC-Ingress-Time: 1585633859980
Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id 71B31B26B2; Mon, 30 Mar 2020 22:50:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=JpfdRNB65hMvWF vzGTnrbDejUzI=; b=hUlrdilRPvftVdRYCu9hm5PO0yzvMDRDq2puRp7f8Xi9yp jEpFg4dezD6pdGL2qYF+RyaDpeHMmLJQAQg1afLhT9TDuYEjWwVRhftbl7oL5TKU 9h8FRRV6fDN1naJraPf8itsZSDnsrvmRSN/ATRt3bG9/OO26jmFEnGsIqb34Q=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id C4E40B26AC; Mon, 30 Mar 2020 22:50:57 -0700 (PDT)
Date: Tue, 31 Mar 2020 00:50:55 -0500
X-DH-BACKEND: pdx1-sub0-mail-a18
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: ietf-http-wg@w3.org, secdispatch@ietf.org
Message-ID: <20200331055054.GQ18021@localhost>
References: <20200329043333.GO18021@localhost> <20200331020629.GD50174@kduck.mit.edu> <20200331045953.GP18021@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200331045953.GP18021@localhost>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedgleelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Received-SPF: pass client-ip=23.83.209.24; envelope-from=nico@cryptonector.com; helo=buffalo.birch.relay.mailchannels.net
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jJ9ns-0004iC-MT 587c50364ff98f00836d33a01a934233
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem
Archived-At: <https://www.w3.org/mid/20200331055054.GQ18021@localhost>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37490
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Mon, Mar 30, 2020 at 11:59:54PM -0500, Nico Williams wrote:
> On Mon, Mar 30, 2020 at 07:06:29PM -0700, Benjamin Kaduk wrote:
> ...
> 
> What about the Redirect scheme?  Have I missed something important?
> That will require IETF Review.  I've added security considerations text
> in my GH repo for this, nicowilliams/accept-auth-and-redirect, FYI.

One thought that occurs is that the Authorization header should only be
preserved from the last redirect: the one back to the original origin.
And a new header could be preserved in all the other hops to enable
communication between the origin and the auth services via the
user-agent.

This way there would be no way for an origin to confuse an auth service
via an Authorization header.  After all, that's for the user-agent to
authenticate to the auth service.  We shouldn't give the Authorization
header two different uses.

On the last redirect, however, we really should want to preserve the
Authorization header, as it will -presumably- be authenticating the user
to the relying party with a token issued by the last hop.

Nico
--