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 remains secret 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 parties to 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 they know (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

Wed, 22 May 2002 11:39:58 -0600 (MDT)
Bear Giles <bear@coyotesong.com>
Security policy