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)
SASLSASL with appropriate plug-ins
UnixUnix 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])
