I-D on dealing with the 3xx XOR 401 problem

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.

See also [2].

Feedback would be greatly appreciated.  Stay safe!

[0] https://tools.ietf.org/html/draft-williams-http-accept-auth-and-redirect-00
    https://www.ietf.org/internet-drafts/draft-williams-http-accept-auth-and-redirect-00.txt

[1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7

[2] https://mailarchive.ietf.org/arch/msg/art/T4nP5Rv91yuE0ew8p0vJh2fX1IM/

Nico
-- 

Received on Sunday, 29 March 2020 04:38:10 UTC