Security policy

I sent this earlier, but accidently sent it from the wrong account
and it's been sitting in the pending spool all day.

Since writing it, I've sketched in server-side GSS-API and SASL
support for my prior patches. The objective isn't to immediately
support either, but to ensure that future support can be added with
minimal effort.

========================================================================

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