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: 200205230026.SAA23996@eris.coyotesong.com (view raw or flat)
Thread:
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
  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

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-2014 The PostgreSQL Global Development Group