Re: 10 weeks to feature freeze (Pending Work)

Sent directly.  Anyone else who's interested can have a copy.  Just  
email me.

I *think* it's structurally sound.  Please tell me if you find a  
problem.  It lacks a lot:  proper specification of required security  
properties, a way to specify different mechanism lists for local,  
vice TCP, vice SSL connections, authN name to authZ name mapping,  
most seriously I didn't implement security layers.  Lots of debug  
checking still needed.

OTOH it works on MacOS 10.4 G4 client and Intel server.

As to the Postgres password database:  If you use the DIGEST-MD5  
mechanism, then you could get a secure, encrypted connection with no  
setup except the PG password.  Also it would have made it easier for  
people to migrate from the current stuff to SASL.

SASL *could* do everything that *any* of the current auth methods can  
do (OK, except ident) and then some.  I thought that exporting all  
that code and functionality to a standard library would be a good  
thing in the long run.  The down side is that completely replacing  
the existing framework would require SASL libraries readily available  
on *all* platforms that PG supports, and Windows doesn't.  The  
Windows SASL API's turn out to be only available on 2K3 server, and  
have never been publicly tested for interoperability with the  
standard Unix library.

I still believe in SASL.  I know the Cyrus SASL library has become  
pretty ubiquitous on Unix platforms.  I wish there were a simpler C  
API than Cyrus.  Java 1.4.2 and up supports it.  There are ways it  
could be provided on Windows, but not within the level of effort that  
Magnus or I can devote to the problem.

---------

For GSSAPI, there is published interop code for the Windows SSPI at  
<http://web.mit.edu/jaltman/Public/kfw/gss/>.  It's more places than  
SASL is.  Down side is it doesn't do much that the current Krb5 code  
doesn't do.

Structurally the GSSAPI mods will be very similar to the SASL ones I  
already did.

On Jan 26, 2007, at 7:16 PM, Stephen Frost wrote:

> * Henry B. Hotz (hotz@jpl.nasa.gov) wrote:
>> If anyone is interested I currently have working-but-incomplete
>> patches to support SASL in C.  I've decided not to finish and submit
>> them because the glue code to make configuration reasonable, and to
>> allow use of existing Postgres password databases with the password-
>> based mechanisms is still significant.
>
> I'd certainly like to take a look at it.  I'm not entirely sure I  
> follow
> what you mean by 'allow use of existing Postgres password databases'-
> I'm not sure SASL support requires that ability (after all, if they  
> want
> to use the 'md5' or similar mechanism they can with the current
> protocol).  Or am I missing something about how the SASL  
> implementation
> is done or intended to be used?  I'd tend to think it'd mainly be used
> as a mechanism to support other authentication mechanisms which don't
> use the internal Postgres passwords...
>
>     Thanks,
>
>         Stephen
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu