Skip site navigation (1) Skip section navigation (2)

Security policy

From: Bear Giles <bgiles(at)coyotesong(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Security policy
Date: 2002-05-23 00:26:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

- 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

* 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

(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.


pgsql-hackers by date

Next:From: Thomas LockhartDate: 2002-05-23 00:31:11
Subject: Re: Interval oddities
Previous:From: Thomas LockhartDate: 2002-05-23 00:20:21
Subject: Re: Redhat 7.3 time manipulation bug

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group