On Thu, 2022-03-17 at 14:03 -0400, Stephen Frost wrote:
> * Andres Freund (andres@anarazel.de) wrote:
> >
> > trust, reject, md5, password, ident, peer, pam, ldap, radius look trivially
> > possible. I think sspi is doable as well, but I don't know it well enough to
> > be confident. gss without transport encryption could have as well, I
> > think. Even scram-sha-256 looks possible, although that'd have been a good bit
> > harder. Where do you see the problems?
>
> I agree with Peter and don't feel like the above actually answered the
> question in any fashion. The question wasn't "which auth methods could
> be implemented using these new set of hooks?" but rather- which could
> have been implemented using a plugin mechanism that was designed
> *before* the new method was considered? The answer to that is
> 'basically none'. There even existed a plugin mechanism (PAM) before
> many of them, and they weren't able implemented using it. That's
> entirely the point- while this might be an interesting way to redesign
> what we have now, should we feel that's useful to do (I don't and think
> it would be an actively bad thing for the project to try and do...)
> there's no reason to believe that it'll actually be useful for the
> *next* auth method that comes along.
We already have the beginnings of a SASL framework; part of the work we
did with the OAUTHBEARER experiment was to generalize more pieces of
it. More generalization can still be done. Samay has shown that one
SASL mechanism can be ported, I'm in the process of porting another,
and we already know that the system can handle a non-SASL (password-
based) mechanism.
So that's a pretty good start.
> > Only stuff tying into transport encryption is clearly not doable via the
> > proposed API, but that's hardly the fault of an authentication API?
>
> This is absolutely the wrong way to look at it. The authentication
> methods that are coming along today are designed to tie into the
> transport encryption because that's *needed* to avoid MITM attacks. I'd
> much rather we generally avoid including ones that don't support that
> and we certainly shouldn't be trying to build a generic system which
> explicitly doesn't support it.
Many SASL mechanisms support channel binding, which the server already
has helpers for, and which SCRAM is already using. At least one SASL
mechanism (GSSAPI) supports the negotiation of transport
confidentiality.
These are answerable questions. I don't think it's fair to ask Samay to
have perfect answers while simultaneously implementing a bunch of
different requests in code and going through the brainstorming process
alongside us all. (It would be fair if Samay were claiming the design
were finished, but that's not what I've seen so far.)
--Jacob
