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

From: Nico Williams <[email-masked]>
Date: Sat, 28 Mar 2020 23:37:48 -0500

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 [email-masked], 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
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Mar 2020 19:06:29 -0700

> This I-D then adds an Accept-Auth request header, and an HTTP

Interestingly, I was just thinking about whether such an Accept-Auth header
would be useful in the context of Rick's SASL proposal that was presented
at SECDISPATCH last week.  Perhaps along with a way for the server to
annotate that various (e.g., linked) resources will require a given
authentication mechanism, there might be a route to improving the UX in
this space ... though there's a long way for it to go, so I don't know that
these in and of themselves will make a huge difference.

-Ben

> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2020 23:59:54 -0500

On Mon, Mar 30, 2020 at 07:06:29PM -0700, Benjamin Kaduk wrote:
> Interestingly, I was just thinking about whether such an Accept-Auth
> header would be useful in the context of Rick's SASL proposal that was
> presented at SECDISPATCH last week.  Perhaps along with a way for the
> server to annotate that various (e.g., linked) resources will require
> a given authentication mechanism, there might be a route to improving

The server isn't going to want to authenticate the user differently for
different resources -- authorize differently, yes, but probably still
with the same scheme.

> the UX in this space ... though there's a long way for it to go, so I
> don't know that these in and of themselves will make a huge
> difference.

I don't quite follow.  There's lots more work to do about UX?  Sure.
But I know this header will make a huge difference for sites where
there's a mix of Negotiate and Bearer -- it's absolutely essential for
the server to know which (if either, possibly both) are supported.  So
I'd very much like to move forward with registering the header by
requesting Expert Review for it.

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.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 31 Mar 2020 00:50:55 -0500

On Mon, Mar 30, 2020 at 11:59:54PM -0500, Nico Williams wrote:
> ...

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 31 Mar 2020 17:29:12 -0500

I've submitted a -01 with these changes:

 - better documented the motivation for the new Accept headers (improved
   interop without having to modify HTTP implementations, just
   applications)

 - removed special values of Accept-Auth

 - added Accept-Redirect and Accept-Redirect-Auth headers

 - for the Redirect auth scheme, limit preservation of the Authorization
   header and add an Authorization-Request header that is always
   preserved

 - expanded discussion of redirect-based auth protocols

 - improved Security and IANA Considerations text

 - misc changes

The new Accept headers and the new auth scheme are now much more
separable.  This I-D could now be split into two I-Ds.

Nico
--