Re: SASL, compression?

> 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