Re: SASL, compression?

I've been looking at the authentication and networking code and
would like to float a trial balloon.

1) add SASL. This is a new standards-track protocol that is often
described as "PAM" for network authentication. PostgreSQL could
remove *all* protocol-specific authentication code and use
standard plug-in libraries instead.

(It's worth noting that SSL/TLS operates at a lower level than
SASL. This has some interesting consequences, see below.)

After the black-box authentication finishes, the postmaster will
have up to pieces of information: the peer's client cert (SSL)
and a string containing the Kerberos principal, user name verified
with password/one-time-password/CRAM, etc.

PostgreSQL authentication would be reduced to specifying which
authentication methods are acceptable for each database, then
mapping that authenticated user string and/or cert to a pguser.

2) add ZLIB compression.

The last point needs a bit of explanation. With SASL, the buffers
may be modified due to the authentication protocol selected, so the
low-level routines in pqcomm.c and fe-connect.c must be modified.
But since this is happening anyway, it would be easy to wrap
sasl_encode with ZLIB compression and sasl_decode with ZLIB decompression,
with pq_flush() (and client's equivalent) doing a "sync flush" of
the compression buffer.

You obviously don't need compression on the Unix socket or a fast
network connection, but if you're on a T1 or slower the reduced
transmission time should more than offset the time spent in
compression/decompression.

Drawbacks

The biggest drawback, at least initially, is that the initial
exchange will need to be totally rewritten. One possibility
could use something like this:

S: 220 example.com PostgreSQL 8.1
C: HELO client.com
S: 250-example.com
S: 250-AUTH ANONYMOUS KERBEROS4 <list of authentication methods>
S: 250-STARTTLS <server accepts SSL/TLS>
S: 250-COMPRESSION <compress datastream>
S: 250 HELP
C: STARTTLS pq.virtual.com <allows virtual domains>
<SSL/TLS negotation occurs *here*>
S: 250-pq.virtual.com
S: 250-AUTH ANONYMOUS PLAIN KERBEROS4 <note extra method>
S: 250-COMPRESSION
S: 250-some extract functions only available with TLS/SSL sessions
S: 250 HELP
C: AUTH PLAIN user password <use simple username/password>
S: 220 OK
C: COMPRESSION ON
S: 220 OK
C: OPEN database
S: 220 OK

and then the system drops back to the existing data exchange
format. Or it could look like something entirely different - the
most important thing is that the server needs to provide a list
of authentication methods, the client chooses one, and it either
succeeds or the client can retry. However a protocol something
like this has the strong advantage of being well-tested in the
existing protocols.

Bear

On Sat, 18 May 2002 11:39:51 -0600 (MDT)
"Bear Giles" <bgiles(at)coyotesong(dot)com> wrote:
> 1) add SASL. This is a new standards-track protocol that is often
> described as "PAM" for network authentication. PostgreSQL could
> remove *all* protocol-specific authentication code and use
> standard plug-in libraries instead.

I'm not that clueful about SASL -- would this mean that we could get
rid of the PostgreSQL code that does SSL connections, plus MD5, crypt,
ident, etc. based authentication, and instead just use the SASL stuff?
Or would SSL/TLS support need to co-exist with SASL?

> 2) add ZLIB compression.

This was discussed before, and the conclusion was that compression
is of fairly limited utility, and can be accomplished by using
ssh -- so it's not worth the bloat. But there were some dissenting
opinions at the time, so this might merit further discussion...

> The biggest drawback, at least initially, is that the initial
> exchange will need to be totally rewritten.

I'd like to see a FE/BE protocol change in 7.4, so this might be a
possibility at that point.

Cheers,

Neil

--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC

Bear Giles <bgiles(at)coyotesong(dot)com> writes:
> 1) add SASL. This is a new standards-track protocol that is often
> described as "PAM" for network authentication. PostgreSQL could
> remove *all* protocol-specific authentication code and use
> standard plug-in libraries instead.

To me, "new standards-track protocol" translates as "pie in the sky".
When will there be tested, portable, BSD-license libraries that we
could *actually* use? I'm afraid this really would end up meaning
writing and/or supporting our own SASL code ... and I think there
are more important things for the project to be doing.

IMHO we've got more than enough poorly-supported authentication options
already. Unless you can make a credible case that using SASL would
allow us to rip out PAM, Kerberos, MD5, etc *now* (not "in a few releases
when everyone's switched to SASL"), I think this will end up just being
another one :-(.

(It doesn't help any that PAM support was sold to us just one release
cycle back on the same grounds that it'd be the last authentication
method we'd need to add. I'm more than a tad wary now...)

> 2) add ZLIB compression.

Why do people keep wanting to reinvent SSH tunneling?

regards, tom lane

> I'm not that clueful about SASL -- would this mean that we could get
> rid of the PostgreSQL code that does SSL connections, plus MD5, crypt,
> ident, etc. based authentication, and instead just use the SASL stuff?

We would still need the ability to map user identities -> pgusers for
those methods where the client can't specify an arbitrary user name
(e.g., Kerberos and GSSAPI), but strictly speaking that's an "authorization"
problem, not an "authentication" problem, and it can be handled entirely
within the backend.

> [W]ould SSL/TLS support need to co-exist with SASL?

Yes. SASL effectively works at the application layer. It's now common
practice for one of the application commands to be STARTTLS (perhaps by
another name) that both sides use as a signal to negotiate a TLS/SSL
session.

The benefit of this approach is that it's easily migrated to Unix
sockets, IPv6, etc.

> > 2) add ZLIB compression.
>
> This was discussed before, and the conclusion was that compression
> is of fairly limited utility, and can be accomplished by using
> ssh -- so it's not worth the bloat. But there were some dissenting
> opinions at the time, so this might merit further discussion...

I agree, it wasn't worth the effort with the existing code. But
if we rewrite the lowest level routines then the amount of bloat can
be minimized.

Bear

> Bear Giles <bgiles(at)coyotesong(dot)com> writes:
> > 1) add SASL. This is a new standards-track protocol that is often
> > described as "PAM" for network authentication.
>
> To me, "new standards-track protocol" translates as "pie in the sky".
> When will there be tested, portable, BSD-license libraries that we
> could *actually* use?

http://asg.web.cmu.edu/sasl/sasl-implementations.html

> Unless you can make a credible case that using SASL would
> allow us to rip out PAM, Kerberos, MD5, etc *now* (not "in a few releases
> when everyone's switched to SASL"), I think this will end up just being
> another one :-(.

http://asg.web.cmu.edu/sasl/sasl-projects.html

If it's being used in Sendmail, Cyrus IMAP and OpenLDAP, with preliminary
work (sponsored by Carnegie Mellon University) in supporting it for CVS
and LPRng and possibly SSH I think it's safe to say it's beyond "vaporware"
at this point.

The only reason I was waving my hands a bit is that I'm not sure if
SASL 2.x is considered production-ready yet. We could support SASL 1.x,
but if 2.x is coming out within 6-12 months then it may make more sense
to target 2.x instead of releasing 1.x today, then switching to 2.x in
the next release.

If there's a concensus that we should proceed, I would also be the
first to argue that we should contact CMU for assistance in the
conversion. Hopefully they have enough experience with their cyrus
package that we can really put this issue to bed. (Meanwhile PostgreSQL
would get more free advertising as another major project using their
SASL library.)

> (It doesn't help any that PAM support was sold to us just one release
> cycle back on the same grounds that it'd be the last authentication
> method we'd need to add. I'm more than a tad wary now...)

Umm... I don't know what to say. This is a common misunderstanding of
PAM (and one reason I *really* hate those PAM Kerberos modules) but people
keep repeating it. PAM was only designed for local use, but people keep
trying to use it for network authentication even though us security
freaks keep pointing out that using some of those modules on a network
will leave your system wide open. In contrast SASL was designed from the
start to work over an untrusted network.

This isn't to say that PAM support is totally useless - it may be a
clean way to handle the ongoing Kerberos principal -> pguser issue, but
it's a nonstarter for authentication purposes unless you know you're
on the Unix socket.

> > 2) add ZLIB compression.
>
> Why do people keep wanting to reinvent SSH tunneling?

One good reason is that secure sites will prohibit them. SSH tunnels
require that clients have shell accounts on the remote system, and
on a dedicated database server you may have no accounts other than the
sysadmins who administer the box.

I'm aware of the various tricks you can do - setting the shell to
/bin/false, requiring RSA authentication and setting the no-tty flag
in the 'known_keys' file, etc., but at the end of the day there are
still extra shell accounts on that system.

SSH tunnels are a good stopgap measure while you add true TLS/SSL
support, but they can't be considered a replacement for that support.

Bear

What are the benefits of SASL+Postgresql compared to Postgresql over plain SSL?

Coz Postgresql already supports SSL right?

Cheerio,
Link.

At 03:11 PM 5/18/02 -0600, Bear Giles wrote:
>If it's being used in Sendmail, Cyrus IMAP and OpenLDAP, with preliminary
>work (sponsored by Carnegie Mellon University) in supporting it for CVS
>and LPRng and possibly SSH I think it's safe to say it's beyond "vaporware"
>at this point.

>I'm aware of the various tricks you can do - setting the shell to
>/bin/false, requiring RSA authentication and setting the no-tty flag
>in the 'known_keys' file, etc., but at the end of the day there are
>still extra shell accounts on that system.
>
>SSH tunnels are a good stopgap measure while you add true TLS/SSL
>support, but they can't be considered a replacement for that support.
>
>Bear

> What are the benefits of SASL+Postgresql compared to Postgresql over plain SSL?

SASL is orthogonal to SSL. SASL is an application-layer library
and can be run over either regular sockets or SSL. However there
are SASL hooks to tell it that it's running over a secure channel.

The anticipated benefit of SASL is that it would replace all of the
current authetication code with a set of standard plugins. The
authority problem would be reduced to a simple text mapping.

(BTW, I didn't make it clear earlier but "authentication" is figuring
out who the other party is, "authority" is figuring out what they're
entitled to do.)

PAM is *not* a solution to network authentication since it was never
designed for it. One well-known nightmare scenario is the Kerberos
PAM modules - they were designed to be used by local users logging
onto a virtual terminal, to eliminate the need to modify login to
acquire Kerberos credentials directly. But in the wild they've been
seen used with Apache "mod_pam" modules to "autheticate" Kerberos
users. Since they require the Kerberos principal and password to be
transmitted across the wire in the clear, they're major security holes
when used this way.

> Coz Postgresql already supports SSL right?

Postgresql minimally supports SSL. It contains some significant
coding errors, poor initialization, and no support for client
certificates. My recent patches should go a long way towards
fixing that.

Bear

At 01:11 AM 5/20/02 -0600, Bear Giles wrote:
> > What are the benefits of SASL+Postgresql compared to Postgresql over
> plain SSL?
>
>The anticipated benefit of SASL is that it would replace all of the
>current authetication code with a set of standard plugins. The
>authority problem would be reduced to a simple text mapping.

[I'm not a pgsql hacker, so feel free to ignore me :) ]

I can see the benefit of SASL as a standard in public exposed network
services like email servers (SMTP, POP, IMAP), where you can support
different email clients which themselves may or may not support SASL and
may use different SASL libraries.

But for Postgresql - communications is mainly between internal db clients
(which use the pgsql libraries) and postmaster.

Would the SASL code allow JDBC, Perl DBI+DBD postgresql clients support
SASL (and encryption) seamlessly? If it would then that's great. If it's
just psql then not so great.

Because replacing current authentication code doesn't seem as obvious a
benefit to me. The plugin thing sounds useful tho - modular. But would the
simple text mapping for authorisation be as simple when UserX is only
supposed to have SELECT access to certain tables?

To me there may be more bang for the buck by improving support for network
layer tunnels- like SSL (SASL has more application layer stuff). Maybe even
support plugins for network layer tunnels, rather than plugins for
authentication. Because Postgresql already provides authentication and
authorisation, we may just need compression/encryption/other tunneling in
various forms.

Would something like this be possible:
For postgresql clients - standardise on two handles for input and output
(ala djb's tcpserver), set environment variables, exec/fork a tunnelapp
with argument string. The tunnelapp will read from output handle, write to
input handle, and make connection to the tunnelserver (which is where
things get difficult - postmaster)..

Then you could have an SASL tunnelapp, an SSL tunnelapp, an SSH tunnelapp.

This would be bad for O/Ses with not so good forks support like solaris and
windows. But the point is - isn't there some other way to abstract the
network/IO layer stuff so that even recompiles aren't necessary?

So if there's a bug in the tunnel app it's not a Postgresql problem - only
the tunnel app needs to be fixed.

> > Coz Postgresql already supports SSL right?
>
>Postgresql minimally supports SSL. It contains some significant
>coding errors, poor initialization, and no support for client
>certificates. My recent patches should go a long way towards
>fixing that.

Cool. WRT the patch which requires strict matches on server hostnames - are
wildcards allowed or is there an option for the client to ignore/loosen
things a bit?

Cheerio,
Link.

> I can see the benefit of SASL as a standard in public exposed network
> services like email servers (SMTP, POP, IMAP), where you can support
> different email clients which themselves may or may not support SASL and
> may use different SASL libraries.
>
> But for Postgresql - communications is mainly between internal db clients
> (which use the pgsql libraries) and postmaster.

Remember that the current authentication code requires that each
database specify the method(s) used to access it. With SASL, it
should be possible to specify generic sensitivities (e.g., 'public,'
'low,' 'high' and 'extreme') and let the systems negotiate any
authentication method that satisfies the properties indicated by
these sensitivities. Including local authentication methods that
we've never heard of.

> Would the SASL code allow JDBC, Perl DBI+DBD postgresql clients support
> SASL (and encryption) seamlessly? If it would then that's great. If it's
> just psql then not so great.

Some clients can allow the user to specify a mechanism, but others
will require the client to autonegotiate the authentication. Exactly
how we'll handle this is one of the open questions.

> Because replacing current authentication code doesn't seem as obvious a
> benefit to me. The plugin thing sounds useful tho - modular. But would the
> simple text mapping for authorisation be as simple when UserX is only
> supposed to have SELECT access to certain tables?

The authorization question HBA deals with is mapping Kerberos principals
to pgusers. That level of authorization is handled by the database,
not postmaster.

> Cool. WRT the patch which requires strict matches on server hostnames - are
> wildcards allowed or is there an option for the client to ignore/loosen
> things a bit?

A lot of CAs won't sign certs with wildcards. They aren't
necessary since you can set up the nameserver to provide aliasing.
It's also possible to add an arbitrary number of altSubjName extensions,
so you could always explicitly name all systems if you wanted.

Adding reverse DNS lookup and support for altSubjName extensions
is on my todo list, but was a lower priority than getting the big
patch out for feedback.

As for loosening the cert verification checks, I think a better
solution is providing a tool that makes it easy to create good certs.
It's too easy to come up with man-in-the-middle attacks if it's easy
to disable these checks.

As a compromise, I think it may be possible to run the server with
*no* cert. This option would be used by sites that only want an
encrypted channel, and sites that want authentication will make the
commitment to creating valid certs.

Bear

Tom Lane wrote:
> Bear Giles <bgiles(at)coyotesong(dot)com> writes:
> > 1) add SASL. This is a new standards-track protocol that is often
> > described as "PAM" for network authentication. PostgreSQL could
> > remove *all* protocol-specific authentication code and use
> > standard plug-in libraries instead.
>
> To me, "new standards-track protocol" translates as "pie in the sky".
> When will there be tested, portable, BSD-license libraries that we
> could *actually* use? I'm afraid this really would end up meaning
> writing and/or supporting our own SASL code ... and I think there
> are more important things for the project to be doing.
>
> IMHO we've got more than enough poorly-supported authentication options
> already. Unless you can make a credible case that using SASL would
> allow us to rip out PAM, Kerberos, MD5, etc *now* (not "in a few releases
> when everyone's switched to SASL"), I think this will end up just being
> another one :-(.
>
> (It doesn't help any that PAM support was sold to us just one release
> cycle back on the same grounds that it'd be the last authentication
> method we'd need to add. I'm more than a tad wary now...)

I agree with Tom on this one. "Plugin" sounds so slick, but it really
translates to "abstraction", and as if our authentication stuff isn't
already confusing enough for users to configure, we add another level of
abstraction into the mix, and things become even more confusing.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026