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

[Nico Williams <[e-mail]>]

On Tue, Feb 07, 2023 at 08:49:59PM -0500, Ken Hornstein wrote:
> You know, I've thought a fair amount about this and I've never really
> been convinced that having the API pick the "best" mechanism out of a
> list is a good idea in the general case.

I tend to agree.

> First, [...]

> Secondly, automatic negotiation tends to "flatten" error reporting.
> [...]

Yes.

> Thirdly, it never seemed to be a good idea to me to automatically pick
> a security mechanism; it seems like what you really want is to specify
> it explicitly. [...]

That's not going to work in HTTP land outside of command-line tools.
User-agent driven interaction for authentication is just not welcomed.
So much so that I think the only thing worth doing in HTTP-land is to
fix up redirect-based authentication so that `Authorization:` headers
can be copied from redirect responses to redirected requests.

I.e., I think adding SASL mechanisms to HTTP will be of marginal use --
not so marginal that I don't think it's worth doing, but not that
enticing either.  And I _believe_ advertising SASL mechanisms separately
will make it harder to adopt.

>         [...]. Most of the SASL security mechanisms have very
> different properties and they're not interchangeable. I realize that's
> not true for all of them and some would be an upgrade from older
> mechanisms, but it's not true in the general case. The better
> applications I've seen that support SASL require you to explicitly
> pick the mechanism you expect to be using. I realize that is not the
> norm in the HTTP world today, but that seems to me to be because there
> is mostly ONE authentication mechanism (basic) in use today. I could
> see a case where a HTTP user-agent tries a bunch of mechanisms and the
> first one that succeeds it remembers and picks that one the next time.

Negotiate is widely used in the enterprise, but not at all on the public
web.  NTLM is still somewhat used in the enterprise, but should really
go away.  Bearer is also used in the enterprise but not on the public
web.  Basic is widely denigrated, hated and avoided.

Only redirect-based schemes (i.e., not HTTP authentication schemes
proper) like OIDC are widely used in the public web and enterprise with
browser user-agents.

I don't see how that changes in the public web.  In the enterprise it's
another story.  Making the various major browsers pluggable for
authentication schemes may allow for adoption of new schemes in the
enterprise, but that's probably it.

I've spent a lot of time in the past several years on bridging
authentication schemes because having just one is not really an option.
Things like JWT token vending that accepts Negotiate (and vice-versa),
online PKI CAs that accept JWT or Negotiate, services that accept JWT
and then impersonate the user using PKINIT to vend a TGT (this could
have been an AS extension, but that was a lot more work), etc.  Having
bridges like that makes it easier to add new schemes, but it's not like
we're clamoring for more schemes!  Apart from PAKEs, what more do we
need?

> This is kind of rambling, and getting back to your original point
> advertising SASL mechanisms together is probably still worthwhile.

You got me rambling too :)

Rick proposes to advertise SASL mechanisms together and separately from
non-SASL HTTP authentication schemes.  I propose to advertise each SASL
mechanism as an HTTP authentication schemes.  This is close to
bikeshedding -- I think the latter will prove easier to implement, but
obviously I've not tried to implement, and everything will depend on
what HTTP user-agent one might be adding SASL support to.

Nico
--