Security policy - Mailing list pgsql-hackers

It occurs to me that part of the problem with wasted and incomplete
efforts can be fixed with a clear security policy.  The part that
I'm interested in is provided below, in a very truncated form.


Secure Communications Channels
------------------------------

Secure communications channels can be provided with Kerberos, GSS-API,
and SSL, and Unix sockets for local communications.  The goals of the 
secure commuications channel are:

* Confidentiality
 Confidentiality means that the data is kept secret from all third parties.

- Perfect Forward Security (PFS)
 Perfect Forward Security is the logical endpoint of confidentiality. It is a form of confidentiality where the data
remainssecret even if the static private keys used by the server (and client) are exposed.
 

* Message Integrity
 Message integrity means that the message received is identical to the message sent.  It is not possible for third
partiesto add,  delete, or modify data midstream.
 

* Endpoint Authentication
 Endpoint Authentication means that the identity of the other party can be firmly established.

- Mutual Authentication
 Mutual Authentication is endpoint authentication by both parties.

- Strong Authentication
 Strong Authentication means that the party has authenticated themselves with at least two of the following: something
theyknow (e.g., password), something they have (e.g., private key, smart card), or something they are (e.g.,
biometrics).

A mechanism to map channel-level authentication (Kerberos principal
name, SSL distinguished name) to PostgreSQL userids is desirable,
but not required.

Initial support for all new protocols shall always include, at a 
minimum, all features present in the sample client and server provided
with the respective toolkit.  Any omissions must be clearly documented
and justified.

The development team shall maintain a matrix cross-referencing each
protocol and the goals satisfied.  Any omissions from normal practice
for each protocol shall be clearly documented and provided to users.
                       | L-SSL | L-KRB | SSL | GSS-API | SASL | Unix
------------------------+-------+-------+-----+---------+------+------
Confidentiality         |   Y   |   N   |  Y  |    Y    |   Y  |   Y  
PFS                     |   N   |   N   |  Y  |    ?    |   ?  |   Y  
Message Integrity       |   N   |   N   |  Y  |    Y    |   Y  |   Y  
Authentication (server) |  N(1) |  ?(2) |  Y  |    Y    |   Y  |   Y  
Authentication (mutual) |   N   |  ?(2) |  Y  |    Y    |   Y  |   Y  
------------------------+-------+-------+-----+---------+------+------
 L-SSL   legacy SSL L-KRB   legacy Kerberos 4 & 5 SSL     current SSL patches GSS-API GSS-API (Kerberos 5
reimplementation)SASL    SASL with appropriate plug-ins Unix    Unix sockets
 

(1) a server certificate is required, but it is not verified by the
client.

(2) PostgreSQL provides some level of authentication via Kerberos 4 and
Kerberos 5, but it may not have been properly implemented.


As I mentioned in an earlier post on -patches, I'm not sure that the
current Kerberos implementation is what people think it is.  I may
develop a GSS-API patch for evaluation purposes, but it will almost
certainly require a different port.

Bear