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

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

Return-Path: <nico@cryptonector.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E4F3A0CF6 for <secdispatch@ietfa.amsl.com>; Mon, 30 Mar 2020 22:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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 MdYMU8rTl39h for <secdispatch@ietfa.amsl.com>; Mon, 30 Mar 2020 22:51:01 -0700 (PDT)
Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (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 261793A0CF5 for <secdispatch@ietf.org>; Mon, 30 Mar 2020 22:51:00 -0700 (PDT)
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/htpmvnnEWzxdiJI6ziSLt2yWOec>
Subject: Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 05:51:03 -0000

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