Re: [HACKERS] SASL, compression?
Tom Lane wrote: Bear Giles [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SASL, compression?
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SASL, compression?
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SASL, compression?
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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SASL, compression?
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SASL, compression?
On Sat, 18 May 2002 11:39:51 -0600 (MDT) Bear Giles [EMAIL PROTECTED] 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 [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SASL, compression?
Bear Giles [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SASL, compression?
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SASL, compression?
Bear Giles [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
