authentication consolidation & SASL

[Bear Giles]

FYI, I'm working on a patch which will consolidate the 
authentication code into several new files

   auth.c       - common code
   authlegacy.c - AUTH_CLIENT & AUTH_SERVER code
   authkrb4.c   - HAVE_KERBEROS specific
   authgssapi.c - HAVE_GSSAPI specific
   authsasl.c   - HAVE_SASL specific

There will be *no* authentication code elsewhere - there will
either be conditional compilation, e.g.,

  #ifdef HAVE_KERBEROS
    connect_to_kserver();
  #endif

or a call through an authentication object, e.g.,

  auth->connect_to_server();

or a combination of both.  (The exact nature is TBD.)  The protocol 
specific files will contain both client & server code.  This is 
usually far clearer than putting the bits in separate files, and 
most files break down into a common pattern:

  common variables

  #ifdef ENCRYPTION
  encryption code - always common to server & client
  #endif

  #ifdef SERVER_SUPPORT
  server code
  #endif

  #ifdef CLIENT_SUPPORT
  client code
  #endif

None of this should be controversial - in fact, it appears to
be the common practice in all other projects supporting multiple
authentication methods.

The authentication object will probably be quite simple:

  typedef struct {
        void *private_data;

    int (*require_encryption) ();
    int (*require_authentication)();

        int (*authenticate_connection)();
        int (*connect_to_server)()

        int (*init)();
        int (*client_close)();
        int (*server_close)();
  } Authentication;
  
  require_encryption() - require data encryption.  Returns 1 if
  acceptable, 0 if undefined (e.g., for legacy) or there's a problem.
  Compare to share_gssapi_encrypt().

  require_authenticat() - require strong authentication.  Returns 1
  if acceptable, 0 if undefined or there's a problem.
  Compare to share_gssapi_encrypt().
 
  authenticate_connection() - authenticates the connection.  Compare
  to ?server_authenticate_connection().

  connect_to_server - connect to server.  Compare to connect_to_?server().

There needs be a factory function, of course, and I'm not sure
how the Kerberos4 "start_tcp_server()" fits into all of this.

However, I have uncovered one oddity which should probably be
cleaned up.  client.c and server.c duplicate a lot of the
low-level functionality, and the code can't be pulled out
into a new file because the names differ.

This might make sense if a single process could ever act as both
client and server, but as far as I know this never occurs.
(I know there's a "connect_to_forked_server", but it should be
possible to avoid conflicts here as well.)  If this is the case,
I believe that it makes the most sense to pull out that duplicate
code into a new file.  The calls would then be largely modularized 
to

{ client, server, root } - { net } - { auth } - { legacy, krb4, gssapi, sasl }


Information on HAVE_SASL

HAVE_SASL will be an additional authentication method using a
SASL layer.  SASL provides authentication & encryption support
via dynamically loaded modules, think "PAM on a wire."  With SASL
support, it should be possible to support additional authentication
methods with little or no effort.

Cyrus-SASL (CMU, BSD-style license) already supports Kerberos4 and GSSAPI,
plus a number of other methods.  Creating a new module to support
CVS passwords should be straightforward.

SASL also provides hooks for TLS/SSL encryption, and I believe it's
possible to act in an "upgrade" mode where the client connects to
the server on the standard port, then requests the channel switch to
TLS.  (Like STARTTLS in SMTP.)  While TLS/SSL provides encryption,
the primary motivation will be the authentication provided with 
digital certs.  It is easy to use the "mini-CA" in OpenSSL to
generate certs suitable for identifying individuals authorized to
access or modify the repository.

Bear Giles
bgiles (at) coyotesong (dot) com