I-D on dealing with the 3xx XOR 401 problem from Nico Williams on 2020-03-29 (ietf-http-wg@w3.org from January to March 2020)

From: Nico Williams <nico@cryptonector.com>
Date: Sat, 28 Mar 2020 23:37:48 -0500
To: ietf-http-wg@w3.org
Cc: secdispatch@ietf.org
Message-ID: <20200329043333.GO18021@localhost>

I've just submitted draft-williams-http-accept-auth-and-redirect-00 [0]
to deal with the problem of the mutual exclusivity of 3xx and 401.

This problem arises when, for example, one mixes in some organization,
both Negotiate [RFC4559] and redirect-based authentication flows. This
problem is rather vexing: the server has to decide which to go with
without knowing which the user-agent supports!

The solution seems simple: let the user-agent tell the server what
authentication schemes it supports. (Indeed, one common hack is to
glean this from the user-agent string.) As well, let the server mix
redirection and authentication requests.

As well, while we're at it, why not codify redirect-based
authentication. In particular, the PowerShell HTTP command-line client,
Invoke-WebRequest [1] has an option to copy Authorization headers from
redirect responses to redirected requests, which seems like just the
ticket:

| -PreserveAuthorizationOnRedirect
|
| Indicates the cmdlet should preserve the Authorization header, when
| present, across redirections.
|
| By default, the cmdlet strips the Authorization header before
| redirecting. Specifying this parameter disables this logic for cases
| where the header needs to be sent to the redirection location.

ISTR seeing a prohibition on copying headers from redirect responses to
redirected requests, but I can't find this now. Digest [RFC2617]
actually describes the Authorization-copying behavior in a paragraph
that straddles pages 17 and 18, using the "domain" parameter of Digest
to effect a redirection.

This I-D then adds an Accept-Auth request header, and an HTTP
authentication scheme named Redirect, and codifies other ways to mix
redirection and authentication requests.

This I-D seems trivial enough to go the ISE route, but perhaps some WG,
such as HTTPbis, might be interested in taking a closer look, reviewing,
possibly leading to request not to publish (if, e.g., there's already a
solution I've missed or this is problematic for some reason), or to
adopting the work.

Cc'ed is secdispatch@ietf.org, in case they want to dispatch this I-D.
Reply-To is set to HTTPbis.