Re: [kitten] Stating support for HTTP-SASL on the HTTP WG list

[Nico Williams <[e-mail]>]

On Tue, Feb 07, 2023 at 10:23:48AM +0000, Rick van Rein wrote:
> > you'd end up
> > with a two-layer negotiation, and we've learned that two-layer
> > negotiations are problematic.
> 
> I can see the problem if the layers require separate messages, because
> you will have made a choice and cannot trace back.  If it is a matter
> of calling a few software stacks, that is a host-local problem.
> 
> The SASL-level mech list is included in the very first 401 message, along
> with the HTTL-level option to use SASL,
> 
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: SASL realm="members only"
>     mech="SCRAM-SHA-256 SCRAM-SHA-256-PLUS GS2-KRB5-PLUS GS2-KRB5"

This can (but does not necessarily) avoid the two-layer negotiation at
the cost of complicating the HTTP user-agent.  You say that's a local
problem, and it is, but local complexity can kill a protocol.

> [...]
> 
> It is possible to continue with, say, ", Digest ..." and allow the
> HTTP-level choice between SASL and Digest.  I'd be interested to see
> if this option is every used in practice; clients are all abound and
> I doubt they can all parse this variability.  In SASL, it's a given.

And here we have the motivation for advertising SASL mechanisms
together: that SASL APIs generally have a function the implements
mechanism selection given the set of mechanisms advertised by the
server, and not using those APIs means replicating the mechanism
selection complexity at the HTTP user-agent layer.

But the HTTP user-agent still has to be aware of the negotiation
details, else we can still have a two-layer negotiation.  Consider a
case where

 - a server offers Digest, SASL{SCRAM}, Negotiate, Bearer

 - the user-agent decides that SASL is best, then it tries it and SCRAM
   fails because there's no credential that could work, but maybe
   Negotiate would have worked

Maybe that's not fatal if the user-agent can use some mechanism, then
try another if the first fails.  But in some cases determining that an
authentication mechanism failed such that another can be tried is not
possible because the response might be a 403 legitimately due to
authorization being denied as opposed to 403 due to failure to
authenticate.

IMO it would be better to treat every [applicable] SASL authentication
mechanism as a distinct HTTP authentication scheme, consequently putting
the whole burden of mechanism selection on the HTTP user-agent layer
[where it already lies today].

> > Also, more generally, I think HTTP authentication schemes are dead.
> > It's too hard to use them generally, especially new ones.
> 
> I have another opinion, especially for RESTful and other autimation
> interfaces.  [...]

I'd like to hear your opinion on that.

>      [...].  And I want an option where browsers can handle credentials
> in a different environment than the one running ads.

That is a different problem.  We can have redirect-based authentication
for origins while denying it for non-origins, for example.  That's a
local problem :)

> > IMO what's really needed is a generic way to do redirect-for-
> > authentication-and-redirect-back-with-a-token.  I think I've an I-D
> > about that somewhere.
> 
> That is a matter of how you decorate the HTTP name space, orthogonal
> to the mechanism used.  This is how I would use it too, indeed.

What namespace.

Nico
--