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

[Ken Hornstein <[e-mail]>]

On Tue, Feb 7, 2023, at 11:32 AM, Nico Williams wrote:
> 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.

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.

First, in my experience it's easy to get this wrong. I've seen a bunch of cases where the "best" mechanism ends up being the wrong one chosen for a particular user. This can happen if (for example) your server advertises that it supports a mechanism like GSSAPI but not all of your users are using that mechanism. The aforementioned SASL APIs generally don't have the ability to determine if you can actually use a particular mechanism until the authentication sequence starts, and by then it's effectively too late.

Secondly, automatic negotiation tends to "flatten" error reporting. In theory this shouldn't be a problem, but from what I've seen more mass market applications tend to want to have relatively simple error reporting and they don't give you the "real" errors; it's something vague like "The password was rejected" because that's the problem 90% of the time, but not always.  And that doesn't really tell you WHICH mechanism it tried.

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

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

--Ken