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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
