Re: Auth extensions, with an LDAP/SCRAM example [was: Proposal: Support custom authentication methods using hooks]

On Tue, Feb 28, 2023 at 6:53 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Jacob Champion (jchampion(at)timescale(dot)com) wrote:
> > Yes. Interoperable authentication is going to have to solve those
> > sorts of problems somehow, though. And there are a bunch of levers to
> > pull: clients aren't required to run their sent usernames through
> > SASLprep; our existing servers don't mind having it sent, so we could
> > potentially backport a client change; and then after that it's a game
> > of balancing compatibility and compliance. A deeper conversation for
> > sure.
>
> We did solve those problems with SCRAM, by not exactly following the
> unfortunately short-sighted standard. What we have gets us the benefits
> of SCRAM and generally follows the standard

"Almost standard" in this case is just a different standard, minus
interoperability, plus new edge cases. I understand why it was done,
and I'm trying to provide some evidence in favor of changing it. But
again, that's a separate conversation; I don't have a patchset
proposal ready to go yet, and I'd rather talk about specifics.

> > But not all of the prerequisites you stated are met. I see no evidence
> > that Active Directory supports SCRAM [1], for instance, unless the MS
> > documentation is just omitting it.
>
> That's certainly unfortunate if that's the case. The question then
> becomes- are a lot of people using SCRAM to connect to OpenLDAP, to the
> extent that it's a sensible thing for us to support and gives us a more
> secure option for 'ldap' auth than what exists today where we're passing
> around cleartext passwords? That seems like it's at least plausible.

I don't know for sure -- I don't have an LDAP userbase to poll for
that, anymore -- but I somewhat doubt it. (And it's moot unless the
compatibility problem is fixed.)

> Broadly speaking, I feel confident saying that authentication systems,
> rather like encryption libraries, should be standardized, well
> documented, heavily reviewed, and carefully maintained.

I mean, I agree with that statement in isolation; those are all
generally good for user safety, which is the end goal. I disagree with
your premise that those goals are achieved by doing everything
in-house, or that letting other people do it is in opposition to those
goals.

Keep in mind, you just explained why it's good that you chose to
depart from the standard in ways that prevent interoperability with
other (reviewed, standardized, maintained) SCRAM implementations, and
that you're generally opposed to backporting compatibility fixes that
would allow migration to those implementations. That doesn't seem
internally consistent to me.

> If the argument
> is that there are these teams out there who are itching to write amazing
> new authentication methods for PG who are going to spend time
> documenting them, reviewing them, and maintaining them, then we should
> try to get those folks to work with the community to add support for
> these new methods so that everyone can benefit from them-

That's not my argument, and even if it were, I think this is
depressingly Postgres-centric. Why would a team of subject matter
experts want to constantly duplicate their work over every network
protocol, as opposed to banding together in a common place (e.g. IETF)
to design an extensible authentication system (e.g. SASL) and then
contributing their expertise to implementations of that system (e.g.
Cyrus, gsasl)?

If you had made those arguments in favor of your own in-house crypto
over OpenSSL -- "Why don't those cryptographers just come here to work
on PG-RSA, which is better than (and incompatible with) regular RSA
because of the changes we made to address their shortsighted designs?"
-- then wouldn't the response be obvious?

> not
> encouraging them to be independent projects which have to work through
> hooks that limit how those authentication methods are able to be
> integrated.

That's a false choice. I don't think we'd have to encourage them to be
fully independent projects, and I don't really want us to design our
own authentication hooks in the end, as I pointed out in my initial
mail.

> Consider things like pg_stat_ssl and pg_stat_gssapi. What
> about pg_ident maps? Will each of these end up with their own version
> of that?

I should hope not. For one, I'd imagine a framework which required
that would be vetoed pretty quickly, and I'm not really here to argue
in favor of bad frameworks. If a particular approach causes terrible
maintenance characteristics, we would probably just not take that
approach.

For two, usermaps are an authorization concern that can usually be
separated from the question of "who am I talking to". There's no
reason for, say, a SCRAM implementation to care about them, because
it's not authorizing anything. (And the OAuth work will hopefully be a
decent bellwether of handling authn and authz concerns with the same
primitives.)

> And those are questions beyond just the issue around making
> sure that these external extensions are well maintained

This sounds a lot like Not Invented Here. Why would it be on you to ensure that?

> and that we
> don't end up breaking them through changes to core.

If we implement core methods using the same framework, that risk goes
way down. Even more so if we use someone else's framework with its own
API guarantees, like we do with e.g. GSS.

--Jacob